The vendor-neutral standard for telemetry, in plain English, and what it does not do for you.
If eBPF is the engine under a lot of modern observability, OpenTelemetry is the language everyone agreed to speak. It is now almost everywhere, and in May 2026 it became a CNCF graduated project, the formal seal on what was already the de facto standard. Here is what OpenTelemetry actually is, why it matters, and the honest limits before you rip out what you have.
What is OpenTelemetry?
OpenTelemetry, usually shortened to OTel, is an open-source, vendor-neutral framework for collecting telemetry: the traces, metrics and logs, and now profiles, that your systems produce. Instead of every vendor shipping its own agent and format, OTel gives you one set of APIs, SDKs and a collector that instrument your applications once and send the data anywhere you choose. It is a Cloud Native Computing Foundation project, second only to Kubernetes in activity, with more than 12,000 contributors from over 2,800 companies, and it reached the CNCF's top maturity tier in May 2026.
The pieces that matter
You do not need the whole glossary, just four parts: the instrumentation, automatic or manual, that produces the data; the OTLP protocol that carries it; the Collector that receives, processes and exports it; and the semantic conventions that keep names consistent, so an HTTP request means the same thing everywhere. Tools like Grafana Alloy are distributions of that Collector, and tools like Odigos produce OTel data with no code changes.
Why it matters
Instrument once, send anywhere. Because the data is standard, you point it at whatever backend you like and switch later without re-instrumenting. That is the end of agent lock-in.
It is the safe long-term bet. With graduation and adoption at this scale, building on OTel is building on the industry default, not a single vendor's roadmap.
It unifies the signals. Traces, metrics and logs in one framework, correlated, rather than three disconnected tools.
The honest ledger
It is a framework, not a backend. OTel collects and ships your data. It does not store, query or visualise it. You still need somewhere for the data to land, whether that is Prometheus, Grafana or a commercial platform.
Maturity varies. Traces and metrics are stable, logs are maturing, and profiles are still early. Some language SDKs are further ahead than others, so check yours.
It adds operational surface. The Collector and its pipelines are powerful, and that power has a cost: more to run, and real discipline needed on data volume and cardinality before the bill surprises you.
Migration is real work. Moving from proprietary agents to OTel pays off, but it is a project, not a switch you flip.
So, is OpenTelemetry for you?
For almost anyone building or running modern systems, yes, and increasingly it is not really a choice: it is the standard your tools already speak. The honest question is not whether to adopt OTel, but how fast, and how much of the pipeline you run yourself versus buy. If you want vendor neutrality and a future-proof foundation, start now, on your most important services. If you need turnkey today, a managed OTel-based offering gets you there without running the plumbing yourself.
Where has OpenTelemetry paid off for you, or tripped you up? I would like to hear it, especially the migration stories. Reply, or book a slot and tell me what you found.
|
Get the next one One signal a week. No noise. | |
|
If this was useful, Metrics & Mayhem sends one short, practical piece like it to IT operations leaders most weeks. No fluff, no vendor noise.
Prefer to start with the book? Read a free chapter. |
Sources / further reading
OpenTelemetry project: opentelemetry.io
OpenTelemetry graduates (CNCF announcement): cncf.io
OpenTelemetry is a CNCF graduated project: opentelemetry.io/blog