The OpenTelemetry Standard

obs1-1's own tip-box promised this chapter would be about correlation, not just collection. obs1-8 previewed the SDK's own shape. This is where both promises land — OpenTelemetry as the vendor-neutral standard unifying all three pillars under one instrumentation approach.

The Problem OpenTelemetry Solves — Vendor Lock-In and Fragmented Instrumentation

Before OTel, each observability vendor — Datadog, New Relic, and others — shipped its own proprietary instrumentation SDK. Switching vendors meant re-instrumenting an entire codebase from scratch. OpenTelemetry, a CNCF project, is the industry's answer: one vendor-neutral standard covering metrics, logs, and traces together, with a shared wire protocol — OTLP — for exporting telemetry to any compatible backend. Instrument once, send anywhere; swapping Jaeger for a different tracing backend, or Prometheus for a different metrics store, becomes an exporter configuration change, not an application code change.

The Three Signals, One SDK

OTel's own vocabulary calls metrics, logs, and traces signals — mirroring obs1-1's own "three pillars" framing, just OTel's specific term for it. The genuine practical payoff: one SDK exposes a tracer, a meter, and a logger side by side, sharing one consistent API — rather than three separate libraries, each with its own conventions, that happen to be used together.

The OpenTelemetry Collector — The Piece That Ties Everything Together

The Collector is a separate, standalone process that receives telemetry over OTLP from instrumented applications, can process or filter it, and exports it to one or more backends. This is the concrete mechanism behind obs1-1's own correlation promise: one pipeline, configured once, feeding Ch.2-4's Prometheus, Ch.7's Loki, and Ch.8's Jaeger from the exact same instrumented application code, with no separate integration work per backend.

Auto-Instrumentation Revisited

obs1-8 previewed this: many OTel language SDKs can auto-instrument common frameworks — HTTP servers and clients, database drivers — with zero code changes, automatically producing spans (and, for the fuller picture this chapter adds, metrics and logs too) for the "boring 80%" of a system's own telemetry. Manual instrumentation, like obs1-8's own process_payment span example, is then reserved specifically for business-specific logic auto-instrumentation could never know to track on its own.

Correlating Signals — The Real Payoff

Because metrics, logs, and traces all flow through the same SDK and the same Collector, they can share correlation context automatically. A log line emitted while a span is active is automatically enriched with that span's own trace ID — the exact same idea obs1-7's own request_id field manually engineered, now produced for free by the underlying mechanism itself:

Metrics get their own version of this same idea via exemplars — a real Prometheus/Grafana feature that attaches an example trace ID directly to a specific data point on a histogram, letting you jump straight from "this latency spike, right here on the graph" to "here's an actual trace from exactly that moment." This is what obs1-1's own tip-box meant by correlation being the real goal, not just having all three pillars collected somewhere.

Hands-On Exercises