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

31–40 of 178 posts

Re: The problem with OpenTelemetry

#31

Post by cdelsolar »

klabb3 wrote: post #26
drewbug01 wrote: post #17

As a contributor to (and consumer of) OpenTelemetry, I think critique and feedback is most welcome - and sorely needed. But this ain’t it. In the opening paragraphs the author dismisses the hardest parts of the problem (presumably because they are human problems, which engineers tend to ignore), and betrays a complete lack of interest in understanding why things ended up this way. It also seems they’ve completely mis…

No dog in the fight here, but… you're saying that one of the top guys at a major observability shop didn’t understand Open Telemetry, then that’s saying much more about OT than it does about his skills or efforts to understand. After all, his main point is that it’s complex and overengineered, which is the key takeaway for curious bystanders like me, whether every detail is technically correct or not. > it just reads…

OTel is very easy to add.. I've added it to several Go projects. For some frameworks like .NET you can do it automatically. The harder/more annoying part is setting up a viewer/collector like Jaeger. I've done that too but just in memory and it fills up quick.

Re: The problem with OpenTelemetry

#32

Post by cogman10 »

cdelsolar wrote: post #30
cogman10 wrote: post #11

Earlier quoted context omitted.

Hey, this isn't the sort of telemetry we are talking about with OTel. About the only "privacy concern" with otel is that you are probably shipping traces/metrics to a cloud provider for your internal applications. This isn't the sort of telemetry getting baked into ms or google that is used to try and identify personal aspects of individuals, this is data that tells you "Foo app is taking 300ms serving /bar which is…

After I added OTel to an open source project I run, I spent a bit of time arguing with someone about telemetry - they kept saying they didn't opt in and that we need to inform our users about it, etc., and I kept saying no, that's not the same type of telemetry. I wonder how common this misconception is.

This is the second time I've seen this misconception come up in HN and I've definitely seen it in Reddit at least once.

Re: The problem with OpenTelemetry

#33

Post by zitterbewegung »

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…

Why have I heard only bad things on k8s? To the point where it’s a meme to understand k8s…

Re: The problem with OpenTelemetry

#34

Post by tnolet »

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…

Can you give an example of the missing semantic conventions?

Re: The problem with OpenTelemetry

#35

Post by yunwal »

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 the same settings for all of them and import separate libraries that all seem to do the same thing by default. Besides sdks and processors, I don't understand the need for these abstractions to persist throughout the pipeline. I'm running one collector, so why do I need to specify where my collector endpoint is 3 different times? Why do I need to specify that I want my blobs batched 3 different times? What's the point of having opentelemetry be one project at all?

My guess is this is just because opentelemetry started as a tracing project, and then became a logs and metrics project later. If it had started as a logging project, things would probably make more sense.

Re: The problem with OpenTelemetry

#36

Post by prymitive »

I only learned about OT after Prometheus announced some deeper integration with it. Reading OT docs about metrics feels like every little problem has a dedicated solution in the OT world, even if a more generalised one already covers it. Which is quite striking coming from the Prometheus world.

Re: The problem with OpenTelemetry

#37

Post by tnolet »

A recent example of OTel confusion.

I could for the life of me not get the Python integration send traces to a collector. Same URL, same setup same API key as for Nodejs and Go.

Turns out the Python SDK expect a URL encoded header, e.g. “Bearer%20somekey” whereas all other SDKs just accept a string with a whitespace.

The whole split between HTTP, protobuf over HTTP and GRPC is also massively confusing.

Re: The problem with OpenTelemetry

#38

Post by hobofan »

This seems to be more of a branding problem than anything.

OP (rightfully) complains that there is a mismatch between what they (can) advertise ("We support OTEL") and what they are actually providing to the user. I have the same pain point from the consumer side, where I have to trial multiple tools and service to figure out which of them actually supports the OTEL feature set I care about.

I feel like this could be solved by introducing better branding that has a clearly defined scope of features inside the project (like e.g. "OTEL Tracing") which can serve as a direct signifier to customers about what feature set can be expected.

Re: The problem with OpenTelemetry

#39

Post by no_circuit »

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 the names of the OTEL community and notice that Sentry is not there: https://github.com/open-telemetry/community/blob/86941073816.... This really isn't news. I'd guess that a Sentry customer should just be able to use the OTEL API and could just configure a proprietary Sentry exporter, for all their compute nodes, if Sentry has some superior way of collecting and managing telemetry.

IMO most library authors do not have to worry about annotation naming or anything like that mentioned in the post. Just use the OTEL API for logs, or use a logging API where there is an OTEL exporter, and whomever is integrating your code will take care of annotating spans. Propagating span IDs is the job of "RPC" libraries, not general code authors. Your URL fetch library should know how to propagate the Span ID provided that it also uses the OTEL API.

It is the same as using something like Docker containers on a serverless platform. You really don't need to know that your code is actually being deployed in Kubernetes. Use the common Docker interface is what matters.

Post reply on HN