Infrastructure & Reliability · Reliability, operations & platforms · Chapter 14 of 33
OpenTelemetry, and what it does not solve
The signal-by-signal maturity people overstate, why the Collector is the real prize, and the problem OTel deliberately left untouched.
OpenTelemetry is the structural change of the last five years in this field, and it is consistently described inaccurately in both directions — oversold on maturity, undersold on what the Collector buys you. It graduated from its foundation in May 2026, which required independent security audits and governance review.
What it actually changed: before OTel, instrumentation was the lock-in. Switching vendors meant re-instrumenting every service, because the agent, the wire format and the data model were all the vendor's. OTel decouples instrumentation from backend. Everything else follows from that.
Maturity, signal by signal — be precise
“OTel is stable for traces, metrics and logs” describes the specification, not the SDK you will actually import.
Traces are stable essentially everywhere. Metrics are stable in the major languages, with exemplars and exponential histograms still able to change. Logs are stable in only a handful of languages — and are still in development for Python and JavaScript, two of the most deployed languages there are.
Profiling is Alpha as of March 2026, and its own working group says it should not be used for critical production workloads and that production-ready backends have not yet emerged.
And there is a second nuance on logs that people miss: OTel deliberately did not build a logging API for application developers. The logs API is a bridge, intended for logging-library authors. You keep your existing logging library and attach an appender. That was the right call — nobody was going to rewrite their logging — but it means ‘OTel logs’ in practice is a bridge whose fidelity depends on the appender.
The accurate sentence names the language, not just the signal.
The Collector, which is the part worth adopting first
The Collector receives, processes and exports telemetry. Five component types: receivers, processors, exporters, connectors and extensions. Two deployment shapes: an agent per host adding local and orchestration metadata, and a gateway tier doing sampling, aggregation and egress control. Serious deployments run both.
- It makes backend choice a config change instead of a code change — and makes dual-writing to two vendors trivial, which is the only thing that makes a competitive bake-off possible at all.
- It puts redaction and filtering of personal data (PII — personally identifiable information) in infrastructure you own rather than in a vendor's agent. That is the point that wins compliance arguments, and it is under-used.
- Component stability is per-component AND per-signal. One component can be stable for traces, alpha for metrics and in development for logs simultaneously. Check the component, not the Collector version.
- The kitchen-sink distribution is for evaluation, not production. Run only the components you need — a focused distribution, a vendor's, or a custom build.
- And it is a capacity-planned stateful service the moment you do anything interesting with it. See the sampling chapter.
Semantic conventions, and the rename that broke everyone's dashboards
There is no ‘semantic conventions 1.0’ — they version continuously. HTTP was the first convention group declared stable, in late 2023, and a long tail of others (database, messaging, generative AI, Kubernetes, cloud) has moved at very different speeds since.
Stabilising HTTP renamed almost every attribute anyone had built a dashboard on — the method, the status code, the URL and the peer name all changed shape. The migration ran through an environment variable with a dual-emit mode so instrumentations could publish both forms during the transition. If you are debugging why a dashboard went blank after an SDK upgrade, this is usually why.
The project has been candid about the cost of that churn. A 2025 stabilisation proposal stated plainly that complexity and lack of stability create impediments to production deployments and that teams do not have the bandwidth to validate and roll out changes at the cadence we ship. That is an unusually honest self-assessment, and it names the real adoption blocker: churn, not capability.
What OpenTelemetry does not solve
Its own documentation is explicit that it is not a backend — storage and visualisation are intentionally left to other tools. Concretely, it gives you none of:
| Not solved | Consequence |
|---|---|
| Storage | You still choose and pay for a backend. This is where essentially all the cost is |
| Query language | There is no OTel query language. You will still learn PromQL and LogQL and TraceQL and whatever your vendor uses. Standardising ingest did not standardise egress |
| Cost | Auto-instrumentation typically emits more spans with richer attributes than the vendor agent it replaced. On a per-GB backend, day one of OTel is a cost increase |
| Cardinality | OTel makes it easier to attach unbounded attributes and provides no guardrail. The explosion risk goes up |
| Sampling policy | It gives you mechanisms and zero guidance on which 1% of traces are worth keeping |
| Dashboards, alerting, SLOs, RBAC, retention | All explicitly out of scope |
The evaluation question that separates marketing from engineering
Every vendor in this market says they support OpenTelemetry. Almost all of them do — they accept OTLP.
OTLP acceptance is universal. OTLP parity is not. Several vendors take your OTLP data and then give you a degraded product compared to their own agent: missing host inventory, missing service maps, missing profiling correlation, missing the feature you saw in the demo. Datadog documents that direct OTLP intake loses metadata enrichment and centralised sampling, and does not populate its own infrastructure host list.
So the question is not “do you support OpenTelemetry?”
It is: “which features of your product do NOT work if I send you pure OTLP with none of your agents installed?”
Ask that in an evaluation and you will get a very different conversation — and it is probably the single best OpenTelemetry interview question there is, because answering it requires having actually tried it.
Check yourself