Every sufficiently large software system eventually needs to answer a simple question: what is it actually doing right now. For most of the industry’s history, answering that question meant picking a monitoring vendor and rewriting your application to speak that vendor’s language. OpenTelemetry changed the economics of that choice, and it’s worth understanding why it happened and what it actually fixed.

The Problem With Bespoke Instrumentation

Before OpenTelemetry, if you wanted distributed tracing, you installed a vendor’s SDK, wrapped your code in that vendor’s spans, and shipped data in that vendor’s proprietary format. Switching monitoring providers meant ripping out instrumentation code across every service and doing it again. This wasn’t an accident. Instrumentation lock-in was a legitimate business strategy for observability vendors, since the cost of migration kept customers in place even when a competitor had a better product or a better price.

The result was duplicated effort across the industry. Every company independently solved the same problem of tagging requests, propagating context across service boundaries, and correlating logs with traces, usually badly, because instrumentation is tedious and easy to get wrong. Engineers spent time maintaining glue code instead of building features.

How OpenTelemetry Works

OpenTelemetry (often shortened to OTel) is a vendor-neutral specification and set of SDKs for generating and collecting three kinds of telemetry: traces, metrics, and logs. The key design decision is separating instrumentation from backend. Your application code emits data in a standard format using OpenTelemetry’s API, and that data gets exported to whatever backend you choose, whether that’s an open source tool like Prometheus and Jaeger or a commercial platform. Switching backends becomes a configuration change instead of a code change.

The other important piece is the OpenTelemetry Collector, a standalone service that sits between your applications and your storage backend. It can receive telemetry in multiple formats, process it (batching, filtering, adding metadata), and export it to one or more destinations simultaneously. This lets teams run multiple backends in parallel during a migration, or fan out data to both a real-time dashboard and a long-term archive without touching application code at all.

Context propagation is the unglamorous but critical part of the spec. When a request crosses from one service to another, OpenTelemetry defines exactly how trace identifiers get passed along, typically via HTTP headers, so that a single user request can be reconstructed as one coherent trace even if it touched a dozen microservices. Getting this right consistently across languages and frameworks is what actually makes distributed tracing useful.

Why Vendors Actually Cooperated

It’s unusual for competing companies to agree on a shared standard that reduces their own lock-in advantage, so the incentives are worth spelling out. Observability vendors realized that instrumentation friction was suppressing the entire market. Companies delayed adopting tracing and metrics tooling because the upfront integration cost was high, and that hurt everyone selling in the space. By collaborating on a shared instrumentation layer under the Cloud Native Computing Foundation, vendors could compete on the actual product, meaning storage, querying, alerting, and analysis, rather than on how hard it was to leave.

The Tradeoffs

OpenTelemetry isn’t free. Instrumentation adds runtime overhead, and if teams aren’t careful with span and label cardinality, they can generate more telemetry data than their backend can affordably store or their bill can absorb. The specification is also large and still evolving, particularly around logs, which matured later than traces and metrics. Some language SDKs are more complete than others, and teams working in less common languages sometimes still hit gaps.

Where This Is Heading

The direction is toward telemetry becoming a default part of frameworks and runtimes rather than something bolted on afterward. As more languages and platforms ship OpenTelemetry support out of the box, the baseline expectation shifts: you shouldn’t have to choose your monitoring vendor before you can see what your own code is doing.