OpenTelemetry

What is OpenTelemetry?

OpenTelemetry (OTel) is the open standard — a CNCF project — for generating and collecting telemetry: traces (the path of a request across services), metrics (numeric measurements over time), and logs, under one unified specification, SDK set, and wire protocol (OTLP). Its core promise is decoupling: instrument your code once against OTel, and send the data to any backend — Datadog, Grafana, Honeycomb, Jaeger, a cloud provider’s service — swapping vendors without re-instrumenting. It has effectively become the industry-standard instrumentation layer.

Why vendor-neutrality is the whole point

Before OTel, observability meant proprietary agents: instrument for Datadog, and migrating to another vendor meant ripping out and replacing instrumentation across your entire codebase — lock-in enforced by sunk instrumentation cost. OTel breaks that. The Collector — a standalone pipeline component — receives, processes (filtering, sampling, enrichment), and exports telemetry to one or many backends, so routing and vendor choice become configuration, not code changes. This is why even the observability vendors adopted OTel: fighting the standard was futile, and it expanded the market. For distributed tracing especially, OTel’s context propagation is what stitches a single request’s journey across dozens of services into one coherent trace.

The practical adoption realities

Traces are the maturest pillar; metrics and especially logs arrived later and vary in stability by language SDK — check maturity for your stack. Auto-instrumentation (drop-in agents/libraries that instrument common frameworks without code changes) accelerates adoption enormously — start there, add manual spans for business-critical logic. Sampling strategy matters: tracing everything at scale is expensive, so head- vs tail-sampling decisions (keep all errors and slow requests, sample the rest) belong in the Collector. And OTel is instrumentation and transport — you still need a backend to store, query, and alert.

What people get wrong

• Expecting OTel to be a backend — it generates and ships telemetry; storage/visualization is a separate choice.
• Ignoring sampling and drowning in cost when full-fidelity tracing hits production volume.
• Manual-instrumenting everything instead of starting with auto-instrumentation and adding spans surgically.

Primary source: OpenTelemetry documentation