Comment by no_circuit | Hacker News Reader

Comment by no_circuit | Hacker News Reader

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.

> IMO this boils down how one gets paid to understand or misunderstand something.

I completely agree. The most charitable interpretation of this blog post is that the blogger genuinely fails go understand the basics of the problem domain, or worst case scenario they are trying to shitpost away the need for features that are well supported by a community-driven standard like OpenTelemetry.

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.

I use sentry selfhosted and started with Otel under gcloud and grafana and everything worked. Perfectly even, with low effort in dotnet.

However with sentry it’s still a pain and the visualization in sentry is kinda weird, since it goes beyond tracing.

And since sentry itself has no otel endpoint it is also really hard to do things like tail sampling.

Can you give more context on what you mean around sampling. What does an OTLP endpoint have to do with it?

multiple services, that should be sampled based on latency. this only works if you have something like: https://github.com/open-telemetry/opentelemetry-collector-co... or https://grafana.com/docs/tempo/latest/configuration/grafana-... in between.

we do use it quite extensivly besides the overhead, because we get lots of insights wenn we have a slow running endpoint.

I think that a number of Observability providers are looking at how they can add features and value to parts of monitoring that OTel effectively commoditizes. Thinking of the tail-based sampling implemented at Honeycomb for APM, or synthetic monitoring by my own team at Checkly.

"In 2015 Armin and I built a spec for Distributed Tracing. Its not a hard problem, it just requires an immense amount of coordination and effort." This to me feels like a nice glass of orange juice after brushing my teeth. The spec on DT is very easy, but the implementation is very very hard. The fact that OTel has nurtured a vast array of libraries to aid in context propagation is a huge acheivement, and saying 'This would all work fine if everyone everywhere adopted Sentry' is... laughable.

Totally outside the O11y space, OTel context propagation is an intensely useful feature because of how widespread it is. See Signadot implementing their smart test routing with OpenTelemetry: https://www.signadot.com/blog/scaling-environments-with-open...

Reply on news.ycombinator.com