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.
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)
The whole idea that some marketing bs has translated to technology fact is why we’re in this mess.
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.
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...
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.)