OpenTelemetry graduated from the CNCF on May 21. It’s now the second most active project in the entire cloud-native ecosystem, behind only Kubernetes. 12,000-plus contributors, 2,800-plus companies, commit volume up around 39% year over year.

If you’ve been waiting to see whether OTel would “win” before committing, stop waiting. It won. The vendor-neutral instrumentation standard is settled.

And that’s the moment the actual work begins.

The war you were fighting is over

For years the observability decision had a strategic fork in it. Do we bet on OpenTelemetry or stay locked to a vendor’s proprietary agent? That question is dead. OTel is the default. Every serious backend speaks it. Instrument once, send anywhere.

This is genuinely good. Lock-in at the instrumentation layer was the worst kind. It made switching vendors a multi-quarter re-instrumentation project, which is exactly why your Datadog bill keeps winning the renewal negotiation.

But “we standardized on OTel” is not a finish line. It’s a decision to operate infrastructure. And the infrastructure has sharp edges nobody warns you about in the conference talk.

What actually bites teams

I see the same OTel pain across Series B-D shops, and it’s almost never “the standard is bad.” It’s operating it.

The Collector is a service you now run in production. The OpenTelemetry Collector sits in the critical path of all your telemetry. It needs sizing, health checks, scaling, and on-call ownership like any other prod service. Teams deploy it once, forget it, and then it silently drops spans under load during the exact incident they needed the data for.

Config breaks between minor versions. This is the complaint I hear most. A Collector config that worked on one minor release throws on the next. Upgrades aren’t routine, they’re a thing you schedule and test, and most teams don’t, so they pin an old version and quietly accumulate risk.

The blockers are people, not technology. The community’s own surveys keep naming the same top three adoption blockers. Implementation complexity, cost, and lack of people who actually know OTel. None of those is a protocol problem. All of them are an operating problem. You can’t helm install your way out of “nobody here understands the pipeline.”

The CNCF noticed. There’s a new “Blueprints” effort kicking off around now, aimed at giving teams reference architectures instead of a box of parts. That it exists at all tells you the gap is real. The standard won, and everyone’s now staring at the operational mess underneath it.

What to actually do

Own the Collector like a tier-1 service. Someone’s name on it. Resource limits, queue and retry config, its own dashboards and alerts. If your telemetry pipeline goes down silently, you’re blind during incidents and you won’t even know it.

Treat Collector upgrades as changes, not chores. Test config against the new version in staging before you roll it. Read the changelog for breaking changes. Pin versions on purpose, not by neglect.

Budget for the volume. OTel makes it trivially easy to emit enormous amounts of telemetry. The standard doesn’t pay your ingest bill. Set sampling and retention deliberately, at the Collector, before the data hits a backend that charges per byte.

And buy the expertise if you don’t have it. The skills gap is the real blocker. Either grow someone into pipeline ownership or bring in someone who’s done it. “We adopted OTel” with nobody who understands it is how you end up with a beautiful standard and a broken pipeline.

The takeaway

Winning the standards war means the easy decision is made for you. It also means the interesting failures move from “which vendor” to “why did our Collector drop half our spans last Tuesday.”

OTel being the default is the best thing to happen to observability in a decade. Just don’t mistake adopting it for being done. You traded a procurement problem for an operations problem. The operations problem is the one that pages you.

The specific ways OTel pipelines go wrong in production, cardinality, dropped context, the costly mistakes, are in my OTel pitfalls guide.

— Youn