Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The problem with OpenTelemetry

cra.mr

Post reply on HN
Print view View original

61–70 of 178 posts

Re: The problem with OpenTelemetry

#61

Post by serverlessmom »

zeeg wrote: post #57
serverlessmom wrote: post #56

An argument that OpenTelemetry is somehow 'too big' is an example of motivated reasoning. I can understand that A Guy Who Makes Money If You Use Sentry dislikes that people are using OTel libraries to solve similar problems. Context propagation and distributed tracing are cool OTel features! But they are not the only thing OTel should be doing. OpenTelemetry instrumentation libraries can do a lot on their own, a frie…

Author here. OpenTelemetry is not competitive to us (it doesn’t do what we do in plurality), and we specifically want to see the open tracing goals succeed. I was pretty clear about that in the post though.

I think that it's disingenuous to say OpenTelemetry and Sentry aren't in competition. I think it would be good news for Sentry if DT were split from the project, and instrumentation and performance monitoring weren't commoditized by broad adoption of those parts of the OpenTelemetry project.

I think you, the author, stand to benefit directly from a breakup of OpenTelemetry, and a refusal to acknowledge your own bias is problematic when your piece starts with a request to 'look objectively.'

Re: The problem with OpenTelemetry

#62

Post by chipdart »

tnolet wrote: post #51
hahn-kev wrote: post #44

Earlier quoted context omitted.

Sounds like a problem with the Python sdk

Well actually. They (python SDK maintainers) argue their implementation is the correct one according to the spec. See this issue thread for example. https://github.com/open-telemetry/opentelemetry-specificatio... There are more. This is a symptom of a how hard it is to dive into Otel due to its surface area being so big.

> Well actually. They (python SDK maintainers) argue their implementation is the correct one according to the spec. See this issue thread for example.

The comment section of that issue gives out contrarian vibes. Apparently the problem is that the Python SDK maintainers refuse to support a use case that virtually all other SDKs support. There are some weasel words that try to convey the idea that half the SDKs are with Python while in reality the ones that support the choices followed by the Python SDK actually support all scenarios.

From the looks of it, the Python SDK maintainers are purposely making a mountain out of a molehill that could be levelled with a single commit with a single line of code.

Re: The problem with OpenTelemetry

#63

Post by chipdart »

NeutralForest wrote: post #2

It resonates. As an intern I had to add OTEL to a Python project and I had to spend a lot of time in the docs to understand the concepts and implementation. Also, the Python impl has a lot of global state that makes it hard to use properly imo.

> As an intern I had to ${DO_SOME_PROJECT} and I had to spend a lot of time in the docs to understand the concepts and implementation

That sounds like every single run-of-the-mill internship.

Re: The problem with OpenTelemetry

#64

Post by serverlessmom »

yunwal wrote: post #35
wdb wrote: post #22

Personally, I like OpenTelemetry, nice standardised approach. I just wished the vendors would have better support for the semantic conventions defined for a wide variety of traces. I quite like the idea of only need to change one small piece of the code to switch otel exporters instead of swapping out a vendor trace sdk. My main gripe with OpenTelemetry I don't fully understand what the exact difference is between (t…

> My main gripe with OpenTelemetry I don't fully understand what the exact difference is between (trace) events and log records. This is my main gripe too. I don't understand why {traces, logs, metrics} are not just different abstractions built on top of "events" (blobs of data your application ships off to some set of central locations). I don't understand why the opentelemetry collector forces me to re-implement th…

Something I mention any time I'm introducing OpenTelemetry is that it's an unfinished project, a huge piece being the unifying abstractions between those signals.

In part this is a very practical decision: most people already have pretty good tools for their logs, and have struggled to get tracing working. So it's better to work on tools for measuring and sending traces, and just let people export their current log stream via the OpenTelemetry collector.

Notably the OTel docs acknowledge this mismatch between current implementation and design goals: https://opentelemetry.io/docs/specs/otel/logs/#limitations-o...

Re: The problem with OpenTelemetry

#65

Post by tnolet »

chipdart wrote: post #62
tnolet wrote: post #51

Earlier quoted context omitted.

Well actually. They (python SDK maintainers) argue their implementation is the correct one according to the spec. See this issue thread for example. https://github.com/open-telemetry/opentelemetry-specificatio... There are more. This is a symptom of a how hard it is to dive into Otel due to its surface area being so big.

> Well actually. They (python SDK maintainers) argue their implementation is the correct one according to the spec. See this issue thread for example. The comment section of that issue gives out contrarian vibes. Apparently the problem is that the Python SDK maintainers refuse to support a use case that virtually all other SDKs support. There are some weasel words that try to convey the idea that half the SDKs are wi…

I guess you word it better than I did.

As a user it feels very weird to wade into threads like this to find a solution to your problem.

The power of Otel is it being an open standard. But the practice shows the implementation of that standard / spec leads to all kinds of issues and fiefdoms

Re: The problem with OpenTelemetry

#66

Post by marcosdumay »

doctorpangloss wrote: post #16

I don’t know what the Sentry guy is really saying - I mean you can write whatever code you want, go for it man. But I do have to “pip uninstall sentry-sdk” in my Dockerfile because it clashes with something I didn’t author. And anyway, because it is completely open source, the flaws in OpenTelemetry for my particular use case took an hour to surmount, and vitally, I didn’t have to pay the brain damage cost most devel…

> eventually everyone is going to learn how to use Kubernetes

That seems obviously true... yet, there are so many people out there that seem unable to learn it that I don't think it's a reliable prediction.

Re: The problem with OpenTelemetry

#67

Post by riedel »

brunoqc wrote: post #59
tnolet wrote: post #50

Earlier quoted context omitted.

Sentry is self hostable. https://develop.sentry.dev/self-hosted/

But not foss. It's using the BSL or FSL or whatever.

Although I do not like those licences, I would not care so much about 2yrs until it goes FOSS. Before all this rush development RRDTool and OpenTSDB was so slow, this whole thing seems rather ideological than substantial criticism. Now going down the licence rabbit hole based to criticise the original argument seems like a classical strawman.

Re: The problem with OpenTelemetry

#68

Post by chipdart »

yunwal wrote: post #35
wdb wrote: post #22

Personally, I like OpenTelemetry, nice standardised approach. I just wished the vendors would have better support for the semantic conventions defined for a wide variety of traces. I quite like the idea of only need to change one small piece of the code to switch otel exporters instead of swapping out a vendor trace sdk. My main gripe with OpenTelemetry I don't fully understand what the exact difference is between (t…

> My main gripe with OpenTelemetry I don't fully understand what the exact difference is between (trace) events and log records. This is my main gripe too. I don't understand why {traces, logs, metrics} are not just different abstractions built on top of "events" (blobs of data your application ships off to some set of central locations). I don't understand why the opentelemetry collector forces me to re-implement th…

> This is my main gripe too. I don't understand why {traces, logs, metrics} are not just different abstractions built on top of "events" (blobs of data your application ships off to some set of central locations).

By design, they cannot be abstractions of the single concept. For example, logs have a hard requirement on preserving sequential order and session and emitting strings, whereas metrics are aggregated and sampled and dropped arbitrarily and consist of single discrete values. Logs can store open-ended data, and thus need to comply with tighter data protection regulations. Traces often track a very specific set of generic events, whereas there are whole classes of metrics that serve entirely different purposes.

Just because you can squint hard enough to only see events being emitted, that does not mean all event types can or should be treated the same.

Re: The problem with OpenTelemetry

#69

Post by zeeg »

no_circuit wrote: post #39

IMO this boils down how one gets paid to understand or misunderstand something. A telemetry provider/founder is being commoditized by an open specification in which they do not participate in its development -- implied by the post saying the author doesn't know anyone on the spec committee(s). No surprise here. Of course implementing a spec from the provider point of view can be difficult. And also take a look at all…

Author here.

Y’all realize we’d just make more money if everyone has better instrumentation and we could spend less time on it, and more time on the product, right?

There is no conspiracy. It’s simple math and reasoning. We don’t compete with most otel consumers.

I don’t know how you could read what I posted and think sentry believes otel is a threat, let alone from the fact that we just migrated our JS SDK to run off it.

Re: The problem with OpenTelemetry

#70

Post by kaashif »

zeeg wrote: post #60
epgui wrote: post #40

Anyone else finding this very difficult to read? I’d really recommend feeding this through a grammar checker, because poor grammar betrays unclear thinking.

So you’re saying it makes my thinking more clear? :) This is what happens when you use a tool designed for authoring code to also author content.

"betrays" means to expose, to be evidence of, particularly unintentionally.

i.e. "poor grammar unintentionally exposed unclear thinking"

Post reply on HN