What the author doesn't realize is that OpenTelemetry has fundamental problems. I experienced this firsthand two years ago working with Otel in Rust, and just today I spent an entire afternoon debugging what turned out to be an otel package update breaking react-router links. Since the bug showed up with several other package updates at once, otel was in the bottom of my suspicion list.

The core issue is that, with otel, observability platforms become just a UI layer over a database. No one wants to invest in proper instrumentation, which is a difficult problem, so we end up with a tragedy of the commons where the instrumentation layer itself gets neglected as there is no money to be made there.

▲

sweetgiorni 2 days ago | parent | next [-]

> The core issue is that, with otel, observability platforms become just a UI layer over a database. No one wants to invest in proper instrumentation, which is a difficult problem, so we end up with a tragedy of the commons where the instrumentation layer itself gets neglected as there is no money to be made there.

I don't think it's fair to say "no one wants to invest in proper instrumentation" - the OpenTelemetry community has built a massive amount of instrumentation in a relatively short period of time. Yes, OpenTelemetry is still young and unstable, but it's getting better every day.

As the article notes, the OpenTelemetry Collector has plugins can convert nearly any telemetry format to OTLP and back. Many of the plugins are "official" and maintained by employees of Splunk, Datadog, Snowflake, etc. Not only does it break the lock-in, but it allows you to reuse all the great instrumentation that's been built up over the years.

> The core issue is that, with otel, observability platforms become just a UI layer over a database.

I think this is a good thing - when everyone is on the same playing field (I can use Datadog instrumentation, convert it to OTel, then export it to Grafana Cloud/Prometheus), vendors will have to compete on performance and UX instead of their ability to lock us in with "golden handcuffs" instrumentation libraries.

▲

andrewstuart2 2 days ago | parent | prev | next [-]

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.

▲

hu3 2 days ago | parent | prev | next [-]

I would add that in most cases, it's just a web UI displaying a lot of noise disguised as data.

Making sense out of so much data is why datadog and sentry make so much money.

▲

csomar 2 days ago | parent [-]

You still have to do that work yourself. I am using honeycomb (the free tier) but their pricing makes little sense. Their margins must be something like x100.

	▲	carefulfungi 2 days ago \| parent [-]
		Having shipped free-tier observability products, your comment that you aren't paying them but think their margins are 100x is a perfect irony.

▲

ehnto 2 days ago | parent | prev | next [-]

The trade off is worth it in this case. Those are technical hurdles, when the issue we are trying to solve is data sovereignty then those hurdles become incidental complexity.

Of course you could also roll your own telemtry, which is generally no that difficult in a lot of frameworks. You don't always need something like OTEL.

▲

PunchyHamster 2 days ago | parent | prev | next [-]

Most languages have pretty mature ecosystem, I used it in Go and it was mostly problem free, with biggest annoyance being a bit of boilerplate that had to be added

▲

tbrownaw 2 days ago | parent | prev [-]

> instrumentation layer itself gets neglected

It needs to be treated as an integral part of whatever framework is being instrumented. And maintained by those same people.