The post says OpenTelemetry has won the standards battle without becoming a good product. Its core complaint is not that observability is unnecessary, but that OTel’s APIs, semantic conventions, collectors, and language implementations have accreted into a sprawling system that is hard to use and slow to mature consistently across traces, metrics, and logs. People reading it largely said that matches reality. The recurring pattern was familiar: tracing can be valuable, vendors increasingly expect OTLP, and OTel is often the only realistic way to keep backend options open, but the day-to-day experience of integrating it is rough.
The sharpest complaints landed on the SDKs and runtime model, not on the idea of a standard. People described global state, static setup, automatic instrumentation, and cross-language abstraction as the root of the pain. Several said OTel feels like Java-era framework design pushed into ecosystems that wanted simple client libraries and explicit dependency injection. That design choice shows up as high
CPU overhead in Python and Ruby, brittle startup behavior in
Django, and awkward fit for newer execution models like durable workflows, long-lived function chains, and serverless runtimes. The same complexity also leaks into the wire format and metric schemas, where commenters said even basic telemetry carries a lot of metadata and machinery.
A second thread clarified where the real tradeoff sits. Many wanted a single instrumentation model that could emit logs, metrics, or traces dynamically. The pushback was blunt: those data types may share source events, but they have different storage, query, and cost profiles, so the backend can unify less than people hope. The practical answer people converged on was not magical late binding. It was to emit richer data than you store, then sample or aggregate aggressively downstream when you can afford it. That works better for some teams than others. High-scale and latency-sensitive environments still see instrumentation overhead as the hard constraint, especially in serverless setups where cold starts and memory budgets make the OTel tax visible.
The dominant conclusion was pragmatic. OTel is still the least-bad common protocol for mixing vendors and tools, and several people said it is perfectly usable once you stop expecting the docs and abstractions to save you. But nobody made it sound elegant. The standard is valuable. The implementation experience still feels overbuilt, inconsistent, and expensive enough that many teams prefer
Prometheus,
Jaeger, vendor-native stacks, or a narrow in-house tracing model unless interoperability is the top requirement.
matduggan.com