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

141–150 of 178 posts

Re: The problem with OpenTelemetry

#141

Post by chipdart »

zeeg wrote: post #128
codereflection wrote: post #121

Earlier quoted context omitted.

Well, telemetry is defined as logs, metrics, traces... So it kinda makes sense that OTEL supports the major aspects of telemetry.

Says who? Sentry has many other types of telemetry and we’ve existed long before OTel. Who are these all knowing humans who say this is what telemetry is? Are they also going to build every collector for every kind of past current telemetry? The whole idea that some marketing bs has translated to technology fact is why we’re in this mess.

> Says who?

For starters, it says so right on the tin.

> Sentry has many other types of telemetry and we’ve existed long before OTel.

That's fine. Just because a vendor is missing features it doesn't mean it's bad. It just scratches a specific itch a specific way. That's ok.

> Who are these all knowing humans who say this is what telemetry is?

For starters, anyone who has any first-hand experience with telemetry, either as users or as implementers.

I seriously don't know what point you are trying to make.

Re: The problem with OpenTelemetry

#142

Post by chipdart »

NeutralForest wrote: post #84
chipdart wrote: post #63

Earlier quoted context omitted.

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

That's fair but I'll say that the time and number of concepts you have to deal with before going into the code, per the docs; is quite big and I think the critic in the article is warranted.

> That's fair but I'll say that the time and number of concepts you have to deal with before going into the code, per the docs; is quite big (...)

That's ok. It's the same for any domain you're just starting to learn. If anyone wishes to, say, onboard onto Cloudwatch or Azure Application Insights they will say exactly the same thing.

Re: The problem with OpenTelemetry

#143

Post by zeeg »

chipdart wrote: post #141
zeeg wrote: post #128

Earlier quoted context omitted.

Says who? Sentry has many other types of telemetry and we’ve existed long before OTel. Who are these all knowing humans who say this is what telemetry is? Are they also going to build every collector for every kind of past current telemetry? The whole idea that some marketing bs has translated to technology fact is why we’re in this mess.

> Says who? For starters, it says so right on the tin. > Sentry has many other types of telemetry and we’ve existed long before OTel. That's fine. Just because a vendor is missing features it doesn't mean it's bad. It just scratches a specific itch a specific way. That's ok. > Who are these all knowing humans who say this is what telemetry is? For starters, anyone who has any first-hand experience with telemetry, eit…

Guess I am unqualified to say that folks who say metrics, logs, and traces are the definition of telemetry is mistaken.

Re: The problem with OpenTelemetry

#144

Post by phillipcarter »

ankitnayan wrote: post #123

I think all of us agree that OpenTelemetry's end-goal of making Observability vendor neutral is futuristic and inevitable. We can complain about it being hard to get started, bloated, etc but the value it provides is clear, esp, when you are paying $$$ to a vendor and stuck with it. OpenStandards also open up a lot of usecases and startups too. SigNoz, TraceTest, TraceLoop, Signadot, all are very interesting projects…

> If everyone cares enough for the bigger picture, the community and existing vendors should get more involved in improving things rather than just complaining.

Speaking as one of these maintainers, I would absolutely love it if even half of the vendors who depend heavily on OTel contributed back to the project that enables their business.

My own employer has done this for years now (including hiring people specifically so they can continue to contribute), and we're only at about 200 employees total. I like to imagine how complete the project would feel if Google or AWS contributed to the same degree relative to the size of their business units that depend on OTel.

Re: The problem with OpenTelemetry

#145

Post by phillipcarter »

dan-allen wrote: post #107

I keep checking in on OpenTelemetry every few months to see if the bits we need are stable yet. There’s been very little progress on the things we’re waiting for. I don’t follow closely enough to comment on possible causes. What I do know is that the surface area of code and infrastructure that telemetry touches means adopting something unfinished is a big leap of faith.

What pieces are you looking to be stable (and what's your definition of stable)?

Asking because some pieces, like the Collector, aren't technically a stable 1.0 yet, but the bar for stability is extremely high, and in practice it's far more stable than most software out there.

But there are other pieces, such as a language's support for a specific concept, that are truly experimental or even still in-development.

Re: The problem with OpenTelemetry

#146

Post by chipdart »

zeeg wrote: post #143
chipdart wrote: post #141

Earlier quoted context omitted.

> Says who? For starters, it says so right on the tin. > Sentry has many other types of telemetry and we’ve existed long before OTel. That's fine. Just because a vendor is missing features it doesn't mean it's bad. It just scratches a specific itch a specific way. That's ok. > Who are these all knowing humans who say this is what telemetry is? For starters, anyone who has any first-hand experience with telemetry, eit…

Guess I am unqualified to say that folks who say metrics, logs, and traces are the definition of telemetry is mistaken.

> Guess I am unqualified to say that folks who say metrics, logs, and traces are the definition of telemetry is mistaken.

I think you're confused. A set of specialized telemetry types is telemetry, and the definition of telemetry is not limited to a subset of soecialied telemetry types. You know, a cat is an animal but the definition of what's an animal is not "a cat".

I recommend you read over the topic. As you seem to complain about anything related to OpenTelemetry, perhaps reading the same answer from other vendors of telemetry systems might spark an epiphany.

https://www.splunk.com/en_us/blog/learn/what-is-telemetry.ht...

Re: The problem with OpenTelemetry

#147

Post by pdimitar »

zeeg wrote: post #78
codereflection wrote: post #74

I understand what the author is saying, but vendor lock-in with closed-source observability platforms is a significant challenge, especially for large organizations. When you instrument hundreds or thousands of applications with a specific tool, like the Datadog Agent, disentangling from that tool becomes nearly impossible without a massive investment of engineering time. In the Platform Engineering professional serv…

I totally agree I just wish we could do it in a way that doesn’t try to lump every problem into the same bucket. I don’t see what it achieves personally, and I think it’s limiting the ability for the original goals of the project to be as successful as they could be.

I'm curious as to what do you mean by "lump every problem into the same bucket"?

As a backender and half platform engineer I appreciate OTel a lot, it allows me to install OTel ingesting code and it then gets sent to wherever our platform guys and girls think it's best. It allows me to only think about it once and leave the details to the people who have to maintain the infra.

I mean sure, parts (or maybe all?) of the problems in this area have other solutions i.e. we don't use OTel for logging because we already have Grafana + Loki and basically everything every app outputs in stdout / stderr gets captured and can be queried but I like the flexibility for us to fully migrate to all aspects of OTel one day if the scales tilt in another direction.

So what's your beef with all this?

(For the record, I used Sentry many times in the past and I loved it, it's a very no-BS product that I appreciated a lot -- and it adding OTel ingester / collector I viewed as something very positive.)

Re: The problem with OpenTelemetry

#148

Post by pdimitar »

marcosdumay wrote: post #137
XCSme wrote: post #135

Earlier quoted context omitted.

Why necessarily Kubernetes? For many applications, it's enough to spin up a VPS/plain Docker container, and it will run fine for many, many years, without adding the Kubernetes complexity on top. If the application is easy to install and autoconfigures itself, it's even better than having to configure everything yourself or create multi-server Kubernetes clusters.

Why you should use kubernetes? You most likely shouldn't. But why should you learn kubernetes? Because everybody else is using it, whether they should or not. Very few people manage to work alone on IT. But anyway, every single possible OT user needs something like kubernetes. It comes first at the scaling requirements.

Learning k8s carries a significant cognitive cost. I've learned hundreds of technologies in my 22+ years of career and I am not about to proactively learn something that people started making certification courses for (and some are quite long, we're talking weeks of training daily). And I am definitely not proactively learning it if it's only 1% likely I'll need it. (I am now working at the second company that actually truly benefits from k8s. Out of 15+.)

I have proactively learned what can k8s do and why is it useful however. That's a context that's very needed because k8s is also a huge investment and you should really know the pros and cons before jumping in. That I did.

Re: The problem with OpenTelemetry

#149

Post by pdimitar »

XCSme wrote: post #136
zitterbewegung wrote: post #33

Earlier quoted context omitted.

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

Personally I could never get into k8s. For most of my use-cases, simply getting a VPS, or having a Dockerfile is enough. Most apps can run fine for millions or hundreds of thousands of user sessions on a $5-$50 VPS. People prematurely optimize for scale, adding a lot of complexity that only makes development slower, and by having more moving parts, there are more things that can break. Start simple. Scaling is mostly…

Yep, strong agree here, and indeed the modern hardware can achieve mind-blowing stuff. I have used a $250 laptop (i5 CPU that's now 8-9 years old, 16GB RAM, SATA SSD) to stress test some of my Rust apps and I could achieve ~250K requests per second.

Sure that doesn't apply to all tech (f.ex. my favorite Elixir is much slower than this) but for most intents and purposes a plain old VPS with good backups is quite enough and always will be. Or if you are particularly paranoid like myself: have a load balancer and have 2-3 copies of your app servers, 1 DB server, and overzealous backup scripts.

Re: The problem with OpenTelemetry

#150

Post by pdimitar »

wvh wrote: post #48

I have surveyed this landscape for a number of years, though I'm not involved enough to have strong opinions. We're running a lot of Prometheus ecosystem and even some OpenTelemetry stacks across customers. OpenTelemetry does seem like one of these projects with an ever expanding scope. It makes it hard to integrate parts you like and keep things both computing-wise and mentally lightweight without having to go all-i…

Could you clarify further on your reservations, please? As a programmer I appreciate only including a library in my project, give it a set OTLP settings (host, port, URI) and move on.

What difficulties did opting into OTel give you?

Post reply on HN