Practical OpenTelemetry — Part 2: Open Standards and the Vendor Shift

Every engineer has lived through a standards war. Betamax vs. VHS. USB-C vs. Lightning. And in observability, a quieter one played out over a decade: every vendor shipped their own agent, their own SDK, their own header formats. Your instrumentation code belonged to whoever you were paying this year.

Practical OpenTelemetry’s second chapter tells the story of how that ended — and why the ending matters more than the story. This post covers the mission behind OpenTelemetry, the “instrument once, export everywhere” promise, and the economic shift that happens when instrumentation becomes a commodity.

The Broken Economics of Instrumentation

Before OpenTelemetry, instrumenting a library was a genuinely thankless task. Consider an HTTP client library author who wants to expose request/response metrics. Their problem, as the book lays it out:

• They must pick an SDK — StatsD? Prometheus? Something vendor-specific?
• That choice doesn’t work with other backends. Users who run Prometheus can’t use a library that speaks StatsD.
• So either the author supports a dozen SDKs, or users are forced into whatever the library happened to choose.

Multiply that across every open-source framework — web servers, database drivers, messaging clients, gRPC, Kafka — and you get the world we actually lived in: most libraries shipped no instrumentation at all, because any choice was wrong for someone. Application owners wrote custom instrumentation against their vendor’s SDK, and that code became the deepest kind of lock-in: migration meant rewriting instrumentation across the entire organization.

OpenTelemetry’s fix is structural. Instead of instruments coupling to an SDK, they couple to a stable API. The library author writes against the API once. The decision of which SDK, which protocol, which backend — all of that is deferred to application configuration and deployment time.

This is the book’s core phrase: “instrument once and export everywhere.” It’s the practical restatement of OpenTelemetry’s own mission: “to enable effective observability by making high-quality, portable telemetry ubiquitous.”

The Mars Climate Orbiter, but for Telemetry

The book reaches for a memorable analogy to explain why standards — not just APIs — matter. On September 23, 1999, the Mars Climate Orbiter was lost approaching Mars because NASA’s software used SI units while Lockheed Martin’s used US customary units. A $327 million spacecraft destroyed by a unit mismatch.

Telemetry has its own version of this problem, and it’s arguably worse: within a single organization, two teams can call the same concept by different names — region, region_name, cloud.region, aws_region, or a legacy data_center reused with a different meaning after a cloud migration. When an alert fires on region: eu-west-1 and the logs say data_center: eu-west-1, correlation tooling can’t magically join them. Someone has to know.

OpenTelemetry’s answer is semantic conventions — a standard vocabulary for naming and decorating telemetry across signals and languages. The same http.server.duration metric means the same thing whether the server was written in Go, Java, or Rust. The same net.peer.name attribute identifies a downstream dependency regardless of client library. (Part 3 of this series dives deep into the conventions; for now, the point is that the standard exists and is enforced by auto-generated code.)

The payoff, from the book’s re-instrumented Payment Service scenario: the alert fires on http.server.duration, tooling correlates it with http.client.duration decorated with net.peer.name: config-service, and one engineer drills into the exact transactions showing the regression — including the DB queries executed by a non-direct dependency. What needed 2–3 teams coordinating now takes one person and no prior knowledge.

Two Projects, One Merger

OpenTelemetry wasn’t built from scratch. It’s the product of a deliberate anti-fragmentation move: in May 2019, OpenTracing (a CNCF project) and OpenCensus (a Google open-source project) merged into OpenTelemetry. Both are now deprecated. The design incorporates elements of both — and more importantly, the merger itself was the message: the industry was tired of competing standards, and the only way to win the standards war was to not have one.

The project’s trajectory since then is impressive by any measure:

• February 2021: specification v1.0.0 — Tracing, Context, and Baggage marked stable
• August 2021: reached incubating status in the CNCF (sandbox → incubating → graduated)
• Backing from virtually every observability vendor: Grafana Labs, New Relic, Splunk, Lightstep — plus Microsoft, Google, Amazon, and Red Hat
• Deep integration with open-source platforms: Prometheus, Jaeger, Grafana Tempo, Pixie

The CNCF maturity model matters more than it sounds. The book maps it to Geoffrey Moore’s Crossing the Chasm adoption curve: sandbox projects serve innovators, incubating projects serve early adopters, graduated projects serve the early majority. OTel hitting incubating means adopting it stopped being a sandbox-stage gamble.

What Vendors Sell After the Shift

Here’s the chapter’s sharpest economic observation: when instrumentation is standardized and portable, the vendor’s value proposition has to move. The old pitch — “use our proprietary agents and SDKs” — had lock-in baked into it, but it also justified the price: the agent was the product.

After OTel, vendors can’t win on ingestion anymore. Anyone can ship telemetry in OTLP format to any backend. So the value migrates to the layer above: advanced analysis and correlation of well-structured, standard telemetry. The book’s framing:

• Vendors refocus on analytics, anomaly detection, and correlation tooling
• Open-source platforms build on the same standards, so the pipeline stops being a differentiator
• Organizations gain freedom of choice — switching backends no longer means rewriting instrumentation

The buy-vs-build decision that used to dominate observability strategy also changes shape. The old dilemma: vendor (lock-in, but managed) vs. open-source (freedom, but you maintain everything). The new reality: the instrumentation and transport layers survive company-wide migrations — you can move from a vendor to an open-source stack (or vice versa) and keep your telemetry architecture intact.

There’s a phrase worth hanging on the wall from this chapter, applied to the whole series: the point of a standard isn’t that it’s perfect — it’s that it’s shared. The Mars orbiter didn’t crash because anyone was stupid; it crashed because two smart teams never agreed on units. OpenTelemetry is the agreement.

Next: Practical OpenTelemetry — Part 3: The Spec, Signals, and Stability — the building blocks: four signals, the API/SDK split, semantic conventions, and how the project keeps backward compatibility promises.

References

• Practical OpenTelemetry (Apress, 2023) — Daniel Gomez Blanco
• OpenTelemetry Mission
• CNCF Project Maturity Model
• Mars Climate Orbiter (Wikipedia)
• Geoffrey A. Moore, Crossing the Chasm