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