OpenTelemetry: Escape Hatch from the Observability Cartel

Re:OpenTelemetry: Escape Hatch from the Observability Cartel by kchoudhu on Friday November 07, 2025 @07:59AM (#45845889)

OpenTelemetry won observability mindshare, but it is entirely the wrong architectural choice: by buying into its ethos your code is held hostage by the least stable otel monitoring library for your dependencies.

Sadly, there was always an alternative that no one took: dtrace. Add USDTs to your code and then monitor progress by instrumenting it externally, sending the resulting traces to wherever you want. My sincere hope is that the renewed interest in ebpf makes this a reality soon: I never want to have to do another from opentelemetry.<whatever> import <whatever> ever again.

[ Parent | on HN ]

Re:OpenTelemetry: Escape Hatch from the Observability Cartel by jitl on Friday November 07, 2025 @08:09AM (#45845949)

If some tracing plug in is shitting up your code with its monkeypatching, rip it out and instrument it yourself. We do this a lot. I’d say Otel packages are no better or worse quality wise than any other stuff in node_modules. Not otel’s fault that Code in general has Bugs and is Bad.

[ Parent | on HN ]

Re:OpenTelemetry: Escape Hatch from the Observability Cartel by rixed on Friday November 07, 2025 @08:30AM (#45846130)

I'm not familiar with usdt, but my understanding is that it covers only the lower level of Opentelemetry. Is there an equivalent of OTLP for dtrace?

[ Parent | on HN ]

Re:OpenTelemetry: Escape Hatch from the Observability Cartel by kchoudhu on Monday November 10, 2025 @02:02AM (#45873209)

I cannot believe it can be too hard to write something that takes the output of dtrace and shoves it into a span collector.

[ Parent | on HN ]