[zeeg]

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.

[unscaled]

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 missing something?

I think the only issue is that the OpenTelemetry API also includes Metrics and Logs. I just tend to ignore these parts when using OpenTelemetry.

[mikeshi42]

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)

[codereflection]

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

[zeeg]

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.

[chipdart]

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

[zeeg]

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

[chipdart]

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

[martinsnow]

Are you having a laugh? Sentry doesn't set the industry standards.

[pdimitar]

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