My first serious observability project was at a bank, and the problem was easy to state and miserable to live with.
The links connecting the ATM network ran through five different providers. Each one had its own dashboard. Five logins, five colour schemes, five definitions of “available” — for one thing the customer experiences as a single service: getting cash out of a machine.
When a machine went down, the first hour was not spent fixing anything. It was spent deciding whose problem it was, in a meeting, with five screens that disagreed.
That is the problem OpenTelemetry solves. Not “modernizing your stack.” Ending the meeting about whose dashboard is right.
🔑 The short version
- OpenTelemetry is a common language for telemetry, not a tool you install instead of what you have.
- It separates producing the data from deciding where it goes — and that separation is the entire point.
- It graduated at the CNCF in May 2026, which in practice makes it the default rather than a bet.
- The real benefit is not technical: it is that changing vendor stops being a rewrite.
- You do not migrate everything. You start with one service, and it coexists with what you already run.
What it actually is, without the jargon
Before OpenTelemetry, every observability vendor had its own agent, its own format and its own libraries. Instrument your code for one of them and your code now speaks that vendor’s private language. Switching later means touching every service you own.
OpenTelemetry replaces that with something almost boring: one agreed way to describe what a system is doing. One vocabulary for a trace, a metric, a log. Your applications emit in that vocabulary, and where the data ends up becomes a configuration decision rather than an architectural one.
The comparison I use in meetings: it is not a new appliance in the kitchen. It is agreeing that everyone writes the orders in the same handwriting, so any cook can read them — including the one you hire next year.
Five providers, five dashboards, one cash machine
Back to the bank, because this is where the abstract part becomes concrete.
Our job was to unify visibility across those five providers, and then correlate it with the state of the network, which lived in yet another system. Nobody in the company had done that integration before. It ended up being three people reading database schemas by trial and error until something returned rows we could use.
It worked. And the lesson I took from it was not about the tooling:
We spent weeks building translation. Not insight — translation. Getting five formats into one shape so a human could compare them. That work produced no new capability; it only made the existing data comparable.
OpenTelemetry is what happens when the industry decides to stop paying for that translation over and over, in every company, forever.
Why it matters if your current tool works fine
This is the objection I hear most, and it is a fair one. If the dashboards are green and the team is happy, why introduce anything?
Because the value shows up at the two moments you cannot schedule:
| The moment | With vendor instrumentation | With a standard |
|---|---|---|
| Renewal negotiation | Leaving means rewriting every service. Your vendor has priced that | Leaving means changing a destination. Different conversation entirely |
| Adding a new tool | Instrument everything a second time, in parallel | Send the same data to two places at once |
| A team picks another platform | Two instrumentation styles, forever | Same data, different views |
| The vendor gets acquired | You find out what your contract really said | You have options while you read it |
None of those are today’s problem. All of them are expensive on the day they arrive, and on that day it is far too late to start standardizing.
The three pieces, and only one of them matters to you
You will see three names thrown around. Here is what each does, in the order you will actually meet them:
- The API — the vocabulary your code uses to say “this operation started, this one failed.” Stable, and the part you want touching your applications.
- The SDK — the machinery that turns those statements into real telemetry and decides how much of it to keep.
- The Collector — a piece that sits in the middle, receives everything, and forwards it wherever you say. This is the one that matters to you as a decision-maker, because it is where “send this to a second vendor” becomes a change in one place instead of a project.
If you remember only one of the three, remember the Collector. It is the component that turns vendor choice into something you can revisit.
It stopped being a bet
Graduation is the CNCF’s highest maturity level, and it is the detail worth taking into a procurement conversation. It means the project is considered stable enough for widespread production use — the same status Kubernetes and Prometheus hold.
Practically, that changes the question you ask a vendor. It is no longer “do you support OpenTelemetry,” because they all say yes. It is whether they ingest it natively or through a translation layer — and the gap between those two answers shows up later as attributes that quietly go missing.
Graduation and maturity: CNCF announcement (May 2026) and InfoQ on the project’s maturity. Components and concepts: OpenTelemetry components and what OpenTelemetry is.
How to start without a migration project
The mistake I see is treating this as a replacement. It is not, and framing it that way is how it gets rejected in the budget meeting.
- Pick one service. Ideally one that already causes arguments about whose fault an incident is. The value is visible immediately there.
- Send the data to where it already goes. Same destination, same dashboards, nothing to relearn. All you changed is the language.
- Then point a copy somewhere else. This is the moment the room understands: the same telemetry, in two platforms, without instrumenting anything twice.
- Leave everything else alone. Coexistence is the normal state, not a transitional embarrassment.
The third step is the demo that wins the argument. Not a slide — the actual thing, with your own data, in a meeting.
Three myths worth killing
| What people say | What is actually true |
|---|---|
| “It replaces my platform” | It replaces the plumbing. You still need somewhere to store, query and alert |
| “We have to migrate everything” | One service is a valid starting point, and it coexists indefinitely |
| “It’s free, so it’s cheaper” | The licence is free; the Collector is infrastructure you operate. Budget for it honestly |
That third one deserves emphasis, because overselling it is how these projects lose credibility. You are not removing a cost. You are moving it — from a vendor’s invoice to your own operation — and buying optionality with the difference.
Frequently asked questions
What is OpenTelemetry in simple terms?
It is a common language for telemetry: one agreed way for applications to describe traces, metrics and logs, regardless of which platform will store them. Before it, every vendor had its own agent and format, so instrumenting your code tied it to that vendor. With a standard, where the data ends up becomes a configuration decision instead of an architectural one.
Does OpenTelemetry replace Datadog, Splunk or Grafana?
No. It replaces the plumbing that carries the data, not the place where you store, query and alert on it. Every major platform ingests it, and you still need one of them. The question to ask a vendor is not whether they support it — they all say yes — but whether they ingest it natively or through a translation layer, because that gap shows up later as attributes that quietly go missing.
Is OpenTelemetry production ready?
Yes. It graduated at the CNCF in May 2026, which is the foundation’s highest maturity level and the same status held by Kubernetes and Prometheus. It is also the second most active project in the foundation. That matters in procurement: adopting it is no longer a bet on a promising project, it is choosing the default.
What is the OpenTelemetry Collector and why does it matter?
It is the component that sits in the middle: it receives telemetry from your applications and forwards it wherever you configure. It matters to whoever owns the budget because it is where sending data to a second platform becomes a change in one place rather than a project. If you remember only one piece of the standard, remember this one — it is what turns vendor choice into a reversible decision.
Do I have to migrate everything at once?
No, and treating it as a migration is how the idea gets rejected. Start with one service — ideally one that already causes arguments about whose fault an incident is — and keep sending its data where it already goes. Then point a copy at a second destination: same telemetry, two platforms, nothing instrumented twice. Everything else can stay as it is indefinitely.
What I take from this
Back to the five dashboards.
What made that project painful was never the technology. It was that five organizations had each described the same reality in their own words, and somebody had to sit in the middle translating before anyone could even start being useful. We were good at it. Being good at it was the problem — it made the translation invisible, so nobody costed it.
A standard does not make your systems better. It removes the tax you were paying to make your own data comparable to itself.
So if you are weighing this: don’t sell it internally as modernization, and don’t promise savings. Sell it as the thing that makes your next vendor decision reversible. That is true, it is checkable, and it is the argument that survives contact with a finance director. 🔭
May the systems be with you. ✦
Featured image generated with artificial intelligence.
Ethel Méndez
Senior Product Manager in B2B observability and networking, with 20 years of field work, NOC and managed services across Latin America. I write what I learned running real systems, not what I read in a course.