I'd just like to point out that you've said OTel has fundamental problems, and then you pointed out a couple examples of one-time-fixable transient problems.

These are issues you'd experience with anything that spans your stack as a custom telemetry library would.

▲

kchoudhu 2 days ago | parent | next [-]

There is very much an alternative. Looking at the execution of your code should never alter its fundamental performance the way otel is built to do. This was a solved problem at least a decade and a half ago, but the cool kids decided to reinvent the wheel, poorly.

https://news.ycombinator.com/item?id=45845889

▲

PunchyHamster 2 days ago | parent | next [-]

dtrace was meant for entirely different use, and it's not a replacement for otel

Otel was made to basically track the request execution (and anything that request triggers) across multiple apps at once, not to instrument an app to find slow points

▲

nothrabannosir 2 days ago | parent | next [-]

To OP’s credit though the latter is exactly what every single piece of otel documentation pushes you to do. Using only the manual spans api is an exercise in api docs spelunking and ignoring “suggested best practices” and “only do this if everything else has failed for you”.

▲

kchoudhu 2 days ago | parent | prev [-]

We should be using USDTs to emit trace ids that can be consumed by dtrace and shoved into whatever backend we want for tracing.

▲

masterj 2 days ago | parent | next [-]

Why don’t you try that, convert the output to OTLP and then write about it?

▲

ok_dad 2 days ago | parent | prev [-]

What’s a USDT? All I can find on Google is crypto garbage.

	▲	tofflos 2 days ago \| parent [-]
		https://illumos.org/books/dtrace/chp-usdt.html#chp-usdt

▲

csomar 2 days ago | parent | prev [-]

That's just one dimension to telemetry. For my use case, for example, I need distributed tracing; which is a fancy word for correlated logs.

▲

csomar 2 days ago | parent | prev [-]

It's more than a couple. The fundamental issue is not the bugs themselves (these are expected) but that, from my perspective, otel is at odds with the observability business because these actors have little interest to contribute back to telemetry agents since anyone can reap the rewards of that. So instead they'd focus more on their platforms and the agents/libraries get neglected.

It's a great idea, in principle, but unless it gets strong backing from big tech, I think it'll fail. I'd love to be proven wrong.

	▲	zja 2 days ago \| parent \| next [-]
		> otel is at odds with the observability business because these actors have little interest to contribute back to telemetry agents since anyone can reap the rewards of that. But all major vendors _do_ contribute to OTEL.
	▲	andrewstuart2 2 days ago \| parent \| prev [-]
		That's kind of how open source works, though. Of course the backend vendors won't care about anything that doesn't affect the backend somehow. But the people, i.e. users, who do want to be able to easily switch away from bad vendors, have incentives to keep things properly decoupled and working. The license is the key enabler for all of this. The vendors can't be all that sneaky in the code they contribute without much higher risk of being caught. Sure, they will focus on the funnel that brings more data to them, but that leaves others more time to work on the other parts.