OpenTelemetry
OpenTelemetry is a vendor-neutral standard and toolkit for generating, collecting, and exporting traces, metrics, and logs.
Definition
OpenTelemetry (OTel) is a CNCF project that defines a common data model and wire protocol for telemetry — traces, metrics, and logs — plus SDKs in every major language and a collector that receives, processes, and exports them. Instrument once against the OTel API and send the data to any compatible backend, decoupling instrumentation from the vendor that stores or displays it. Context propagation ties the three signals together.
Context and scope
The default instrumentation layer for new services and for teams avoiding vendor lock-in in their observability pipeline.
Common misconceptions
- OpenTelemetry is a backend — it is instrumentation and transport; you still need a store such as a tracing or metrics service
- Adopting OTel means rewriting all monitoring — auto-instrumentation plus the collector can bridge existing sources
- Signals can be added later without cost — every span and metric has runtime and storage cost that must be sampled
Anti-patterns
- Instrumenting with vendor-specific agents and APIs that force a later migration
- Sending every span at full fidelity with no sampling, overwhelming the collector and the budget
- Exporting to the collector synchronously on the request path, adding latency to every call
Related concepts
Related examples
Authoritative source
What it is
OpenTelemetry standardises telemetry generation and transport. Language SDKs emit spans, metrics, and log records against one API, attach resource attributes describing the host and service, and propagate context between processes. A collector — a standalone receiver-processor-exporter pipeline — centralises sampling, enrichment, and routing, so applications only know the OTel protocol while backends remain swappable.
Why it matters
Observability vendors change and pricing shifts, but instrumentation embedded in application code is expensive to rewrite. OTel breaks that coupling: instrument once, and change vendors by editing a collector config. Using one model across traces, metrics, and logs also means a span can carry a trace id that links it to the exact log line and the metric spike for the same request.
How to adopt it
Start with auto-instrumentation to get traces for HTTP, database, and RPC calls at low effort, then add manual spans only around the business logic that needs to be visible. Run the collector as the single exporter, apply tail-based sampling there, and keep resource attributes consistent so services can be grouped. Establish naming conventions early, because signal quality degrades quickly when every team invents its own metric names.