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

131–140 of 178 posts

Re: The problem with OpenTelemetry

#131

Post by mikeshi42 »

unscaled wrote: post #117
zeeg wrote: post #78

Earlier quoted context omitted.

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 not sure I get what's the problem with OpenTelemetry as it is then? I'm not familiar with the JavaScript implementation, but it seems to be modular. You can just import @opentelemetry/api and @opentelemetry/sdk-trace-web, and as far as I understand you'll get the API (annotations) and the tracing implementation, but without the exporter (OTLP). You can plugin your own exporter or even just use the API - am I miss…

No you're not missing anything, it is that simple. With @opentelemetry/auto-instrumentations-node you can actually get the OTLP exporters "for free" as well if you require the register script.

Logs in JS is really only significant as a wire format + some transport glue code for popular loggers so it can be more or less completely ignored. I do find the Otel metrics model overcomplicated compared to OpenMetrics, though not to say OpenMetrics doesn't have its own set of tradeoffs.

With metrics and logs, I do see the advantage of a single project driving unification of signals as opposed to treating them as silos. With one set of semantic conventions and SDK available, it'll be a lot easier to tie everything together, rather than relying on engineers to do that themselves via timestamps and glancing across 3 different tabs.

I think the OP author bias here is that Sentry only really cares about the Otel instrumentation libs for tracing to power their APM product, and everything else is superfluous (hence the blog). I help build HyperDX, where we care about unifying metrics/logs along with traces, and having it all in one ecosystem is quite important for making it work well - and we do not find the rest of it superfluous! (disclaimer: obviously biased in my own ways)

Re: The problem with OpenTelemetry

#132

Post by theBaus »

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.

[dead]

Re: The problem with OpenTelemetry

#133

Post by wdb »

arccy wrote: post #83
yunwal wrote: post #35

Earlier quoted context omitted.

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

If you're using OTLP, SDKs only require you specify the endpoint once, the signal specific settings are for if you want to send them to different places. The way you process/modify metrics vs logs vs traces are usually sufficiently different that there's not much point in having a unified event model if you're going to need a bunch of conditions to separate and process them differently. Of course, you can still use o…

Well, only when you use the OTLP protocol and otel-collector. In other cases you would need a (span) exporter to multiple targets at the same time. But yeah, otel-collector would be the best approach to achieve this.

Re: The problem with OpenTelemetry

#134

Post by yunwal »

lloeki wrote: post #124
yunwal wrote: post #114

Earlier quoted context omitted.

> Just because you can squint hard enough to only see events being emitted If you squint hard enough you can fool yourself into thinking all metrics have the same availability requirements. It’s not the case. There are plenty of time series data metrics where arbitrarily dropping them or aggregating them would throw off your alerting entirely.

Indeed one would have to squint to the point of blindness. Logs are single point in time, flat, linear sequence, never dropped (at best you'd collapse sequences of identical, repeated logs). Think dmesg, syslog, systemd journald/journalctl. Metrics are statistical numeric data, which can be series, average, histogram, bucket... aggregation/reduction can be done on the fly/before leaving the observed thing. Some can b…

Right, the point I’m making is logs, metrics, traces, these concepts are views of data, with a pretty hazy relationship to the shape of the data itself or the handling requirements. Any assumption you make about them as a category (logs are unstructured, traces are sampled, metrics can be aggregated) is wrong nearly as much as it’s right.

Re: The problem with OpenTelemetry

#135

Post by XCSme »

marcosdumay wrote: post #66
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.

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.

Re: The problem with OpenTelemetry

#136

Post by XCSme »

zitterbewegung wrote: post #33
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…

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 a solved problem nowadays, if you quickly need to scale, there are always solutions to do so. In the worst case, you have to scale horizontally, and if you reach the limit of horizontal scaling, other your app is inefficient, or your business is already successful, so you are no longer in the "start" phase.

Re: The problem with OpenTelemetry

#137

Post by marcosdumay »

XCSme wrote: post #135
marcosdumay wrote: post #66

Earlier quoted context omitted.

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

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.

Re: The problem with OpenTelemetry

#138

Post by dtjohnnymonkey »

> That means what we actually want is a way to say “hey OpenTelemetry SDK, give us all the current spans in the buffer”.

Isn’t this exactly what the SpanExporter API is for? This is in the Go SDK, I suppose it may not be available in other SDKs.

I have used this API to convert OTel spans into log messages as we currently don’t have a distributed tracing vendor.

Re: The problem with OpenTelemetry

#139

Post by chipdart »

yunwal wrote: post #114
chipdart wrote: post #68

Earlier quoted context omitted.

> 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 sa…

> Just because you can squint hard enough to only see events being emitted If you squint hard enough you can fool yourself into thinking all metrics have the same availability requirements. It’s not the case. There are plenty of time series data metrics where arbitrarily dropping them or aggregating them would throw off your alerting entirely.

> If you squint hard enough you can fool yourself into thinking all metrics have the same availability requirements.

I'm sorry, I have no idea what point you tried to make.

Re: The problem with OpenTelemetry

#140

Post by chipdart »

yunwal wrote: post #134
lloeki wrote: post #124

Earlier quoted context omitted.

Indeed one would have to squint to the point of blindness. Logs are single point in time, flat, linear sequence, never dropped (at best you'd collapse sequences of identical, repeated logs). Think dmesg, syslog, systemd journald/journalctl. Metrics are statistical numeric data, which can be series, average, histogram, bucket... aggregation/reduction can be done on the fly/before leaving the observed thing. Some can b…

Right, the point I’m making is logs, metrics, traces, these concepts are views of data, with a pretty hazy relationship to the shape of the data itself or the handling requirements. Any assumption you make about them as a category (logs are unstructured, traces are sampled, metrics can be aggregated) is wrong nearly as much as it’s right.

> Right, the point I’m making is logs, metrics, traces, these concepts are views of data (...)

Not really. Logs are fundamentally different than operational metrics, which are fundamentally different than business/behavioral metrics, which are fundamentally different than traces, etc etc etc.

This is not a matter of "view". It's the result of completely different system requirements. They are emitted differently, they are processed/aggregated differently, they are stored differently, they are consumed differently.

Even within business metrics types, which is already a specialized type of metrics, you have fundamentally different system requirements. Click stream metrics mix traits of tracing with logging and metrics, and have very specific requirements regarding data protection.

They are all distinct observability features. They are not the same. At all. This is not up for debate.

Post reply on HN