OpenTelemetry
The open standard for instrumenting metrics, logs, and traces with one API and forwarding to any backend. Replaces vendor-specific agents. The CNCF standard that decouples instrumentation from the storage backend.
- Any new observability setup.
- Avoiding vendor lock-in across backends.
- Existing mature vendor-specific setups with no need to change.
- Tiny apps where it's overkill.
Definition
OpenTelemetry (OTel) provides APIs/SDKs to instrument code once and export metrics, logs, and traces to any backend (Prometheus, Tempo, Datadog) via the OTLP protocol. It standardizes context propagation and semantic conventions.
Why it exists
Vendor lock-in and re-instrumentation per backend were painful. OTel gives a single instrumentation layer that works with any backend, standardizing context propagation across services.
How it works
Instrument with OTel APIs; the SDK samples and exports via OTLP to a collector, which fans out to backends. Context (trace context, baggage) propagates automatically across HTTP/messaging. Semantic conventions standardize attribute names.
Scaling limits
Adoption across polyglot stacks and legacy code is gradual. The collector adds a component to operate. Some signals (logs) are less mature than traces/metrics.
Cost shape
Free (open source). Cost is the collector infra and the backend you choose. Blow-ups: over-instrumentation and high export volume.
Alternatives
- Vendor SDKs — Tighter integration but lock-in.
- Prometheus + Jaeger separately — Works, but no unified context/SDK.
Failure modes
- Incomplete context propagation.
- Over-instrumentation cost.
- Collector as a new failure point.