3 ms·

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 t

by csomar 1y ago

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.

hu3 1y ago
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 1y ago
  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 1y ago
    Having shipped free-tier observability products, your comment that you aren't paying them but think their margins are 100x is a perfect irony.
    - cstrahan 11mo ago
      It sure sounds like the problem is subsidizing the free tier by making the paid tiers excessively expensive. That in turn drives people to squeeze as much out of the free tier as they can, complain online, and jump ship to either a different service or self hosting. So... maybe don't do that?
ehnto 1y ago
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.
andrewstuart2 1y ago
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.
- csomar 1y ago
  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.
  - andrewstuart2 1y ago
    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.
  - zja 1y ago
    > 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.
- kchoudhu 1y ago
  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 https://news.ycombinator.com/item?id=45845889
sweetgiorni 1y ago
> 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.
tbrownaw 1y ago
> 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.
PunchyHamster 1y ago
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

by csomar 1y ago

hu3 1y ago

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 1y ago
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 1y ago
  Having shipped free-tier observability products, your comment that you aren't paying them but think their margins are 100x is a perfect irony.
  - cstrahan 11mo ago
    It sure sounds like the problem is subsidizing the free tier by making the paid tiers excessively expensive. That in turn drives people to squeeze as much out of the free tier as they can, complain online, and jump ship to either a different service or self hosting. So... maybe don't do that?

ehnto 1y ago

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.

andrewstuart2 1y ago

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.

csomar 1y ago
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.
- andrewstuart2 1y ago
  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.
- zja 1y ago
  > 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.
kchoudhu 1y ago
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 https://news.ycombinator.com/item?id=45845889

sweetgiorni 1y ago

> 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.

tbrownaw 1y ago

> 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.

PunchyHamster 1y ago

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