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

11–20 of 178 posts

Re: The problem with OpenTelemetry

#11

Post by cogman10 »

aleph_minus_one wrote: post #8
antonyt wrote: post #6

OTel is flawed for sure, but I don't understand the stance against metrics and logs. Traces are inherently sampled unless you're lighting all your money on fire, or operating at so small a scale that these decisions have no real impact. There are kinds of metrics and logs which you always want to emit because they're mission-critical in some way. Is this a Sentry-specific thing? Does it just collapse these three kind…

> OTel is flawed for sure, but I don't understand the stance against metrics and logs. Even if you don't want to consider the privacy concerns: telemetry wastes quite some data of your internet connection .

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

Re: The problem with OpenTelemetry

#12

Post by dboreham »

I've used Otel quite a bit (in JVM systems) and honestly didn't know it did more than tracing.

That said, I think this rot comes from the commercial side of the sector -- if you're a successful startup with one product (e.g. graphing counters), then your investors are going to start beating you up about why don't you expand into other adjacent product areas (e.g. tracing). Repeat previous sentence reversed. And so you get Grafana, New Relic, et al). OpenTelemetry is just mirroring that arrangement.

Re: The problem with OpenTelemetry

#13

Post by Karrot_Kream »

BiteCode_dev wrote: post #3

100% agree. Every time I tried to use OT I was reading the doc and whispering "but, why? I only need...".

Yeah I was going down this path for a side project I was getting going and spent a couple days of after-work time exploring how to get just some basic traces in OT and realized it was much more than I needed or cared about.

Re: The problem with OpenTelemetry

#14

Post by cogman10 »

Perhaps the real problem with OTel (IMO) is it's trying to be everything for everyone and every language. It's trying to have a common interface so that you can write OTel in Java or Javascript, python or rust, and you basically have the exact same API.

I suspect OP is seeing this directly when talking about the cludgyness of the Javascript API.

Re: The problem with OpenTelemetry

#16

Post by doctorpangloss »

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 developers hate: relationships with yet another vendor.

That said I appreciate all the innovation in this space, from both Sentry and OpenTelemetry. The metrics will become the standard, and that’s great.

The problem with Not OpenTelemetry: eventually everyone is going to learn how to use Kubernetes, and the USP of many startup offerings will vanish. OpenTelemetry and its feature scope creep make perfect sense for people who know Kubernetes. Then it makes sense why you have a wire protocol, why abstraction for vendors is redundant or meaningless toil, and why PostHog and others stop supporting Kubernetes: it competes with their paid offering.

Re: The problem with OpenTelemetry

#17

Post by drewbug01 »

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 misunderstood the API/SDK split in its entirety - because they argue for having such a split. It’s there - that’s exactly what exists!

And it goes on and on. I think it’s fair to critique OpenTelemetry; it can be really confusing. The blog post is evidence of that, certainly. But really it just reads like someone who got frustrated that they didn’t understand how something worked - and so instead of figuring it out, they’ve decided that it’s just hot garbage. I wish I could say this was unusual amongst engineers, but it isn’t.

Re: The problem with OpenTelemetry

#20

Post by arccy »

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…

indeed, it just sounds like they're complaining they don't have a seat at the table...
Post reply on HN