For years, getting visibility into a distributed system meant choosing an observability vendor and then instrumenting code with that vendor’s proprietary agent. Switching providers meant re-instrumenting everything, which made the choice feel permanent. OpenTelemetry, a project under the Cloud Native Computing Foundation, set out to change that by defining a single, vendor-neutral way to produce traces, metrics, and logs. By 2026 it has become the default way many teams instrument new services, and most major observability vendors accept its data. That success hides a more nuanced picture, though. Standardizing how telemetry is produced does not make it cheap, easy to interpret, or free of operational burden. Here is an honest look at what OpenTelemetry solved and what teams still have to get right.
What the Standard Actually Solved
The core win is decoupling instrumentation from the backend. Teams instrument code once using OpenTelemetry’s APIs and SDKs, then send the data wherever they like through the OpenTelemetry Collector, a configurable pipeline that can receive, process, and export telemetry to one or many destinations. Because the format is shared, changing vendors, or running a self-hosted backend such as Jaeger for traces and Prometheus for metrics alongside a commercial one, no longer means rewriting instrumentation. Automatic instrumentation for popular languages and frameworks also lowers the barrier, capturing common requests and database calls with little code. For organizations tired of lock-in, this portability is the headline benefit.
The Parts That Are Still Hard
Standardization did not remove the difficulty of deciding what to measure. Auto-instrumentation produces plenty of data but not necessarily useful data, and teams still need to add meaningful custom attributes, such as customer tier or feature flag, to answer real questions. The three signals also matured at different speeds. Tracing and metrics became stable first, while logging support took longer, so teams adopting it may still find uneven maturity across languages. Correlating a slow trace with the matching logs and metrics requires consistent context propagation across every service, and a single service that drops trace headers can break the picture for everything downstream.
The Real Cost Problem
The most common frustration in 2026 is not instrumentation but cost. Telemetry volume grows quickly in a microservices architecture, and storing and querying all of it can become one of the larger line items in an infrastructure budget. High-cardinality attributes, such as user IDs placed on metrics, can multiply storage and query costs dramatically. This is why sampling strategy matters: keeping every trace is rarely affordable, so teams use head or tail sampling in the Collector to retain errors and slow requests while discarding routine ones. Getting sampling and retention policy right is now as important as the instrumentation itself, and it requires deliberate ownership rather than defaults.
Should Your Team Adopt It Now
For new services and for organizations that want to avoid vendor lock-in, instrumenting with OpenTelemetry is the sensible default in 2026, and the ecosystem is mature enough that few teams regret it. For existing systems already well served by a vendor’s agent, a full migration is rarely urgent; many teams adopt it gradually, instrumenting new code with OpenTelemetry while leaving stable services alone. Small teams running a handful of services may not need distributed tracing at all, and solid logs and basic metrics can be enough. As with most infrastructure choices, the question is not whether the standard is good, but whether the visibility it enables is worth the data cost and discipline it demands.
Looking across how teams have actually adopted OpenTelemetry, a pattern emerges. The organizations getting the most value treat observability as a product with an owner, deciding which attributes matter, how long data is kept, and how much sampling is acceptable. Those that simply turned on auto-instrumentation and sent everything to a backend often ended up with large bills and dashboards nobody trusted. The standard’s greatest contribution is freedom, since instrumentation is now an investment that survives a change of vendor. What it cannot provide is judgment about what to look at, and that remains an engineering responsibility. Expect continued maturing of logging support and tooling around cost control.
Conclusion
OpenTelemetry delivered on its core promise: instrument once, send anywhere. That alone changed the economics of choosing and switching observability tools. It did not turn telemetry into insight automatically, and the challenges of cost, context propagation, and sampling remain real. Teams that pair the standard with clear ownership and sensible data policies get the benefits; those that treat it as a switch to flip tend to get a large bill instead.
