OpenTelemetry is a CNCF project that provides a specification, APIs, and the OTLP protocol for generating and exporting traces, metrics, and logs. It standardizes telemetry collection across languages and backends for observability.
OpenTelemetry
OpenTelemetry is a CNCF project that provides a single set of specifications, APIs, SDKs, and the OTLP wire protocol for generating and exporting traces, metrics, and logs. Formed from the merger of OpenTracing and OpenCensus, it gives applications one vendor-neutral way to instrument code and ship telemetry to any compatible backend. That decoupling of instrumentation from vendor is what makes it the de-facto standard for observability.
- Three signals - Traces, metrics, and logs are covered by one coherent data model rather than three disconnected tools.
- OTLP protocol - The OpenTelemetry Protocol defines how telemetry moves from applications to collectors and backends over gRPC or HTTP.
- Collector - A standalone agent receives, processes, and routes telemetry, so pipelines can be reshaped without touching application code.
- Vendor-neutral instrumentation - Instrument once against the OTel API, then point the data at any observability vendor without re-instrumenting.
In real API operations, OpenTelemetry is how a request is followed across service boundaries — each API call carries trace context so latency, errors, and dependencies are visible end to end. Standardizing on OTel means an organization can switch or combine observability vendors without rewriting instrumentation, and governance teams can insist on one telemetry contract across every service. Paired with OpenMetrics for the metrics format, it anchors a portable observability stack that also gives agents a consistent, machine-readable view of how APIs actually behave in production.
Open source tools that implement this standard
Harvested from this standard's own governing organisation, with the license read from each repository rather than assumed. The role is what the tool does to the specification, from the shared vocabulary — so an agent holding one of these documents can resolve straight from a goal to a tool.
| Tool | Role | License | What it does |
|---|---|---|---|
| OpenTelemetry Collector | instruments |
Apache-2.0 | Receives, processes and exports telemetry in a vendor-agnostic pipeline — the component that decouples what emits telemetry fro... |
| OpenTelemetry Go | instruments |
Apache-2.0 | The Go API and SDK for producing traces, metrics and logs in OTLP. |
| OpenTelemetry Collector Contrib | instruments |
Apache-2.0 | The community distribution of the Collector, carrying the long tail of receivers, processors and exporters for specific vendors... |
| OpenTelemetry JavaScript | instruments |
Apache-2.0 | The JavaScript and TypeScript API and SDK for OTLP telemetry, in Node and the browser. |
| OpenTelemetry Java Instrumentation | instruments |
Apache-2.0 | Automatic instrumentation for the JVM — attaches as a Java agent and produces telemetry from common frameworks with no code cha... |
| OpenTelemetry Python | instruments |
Apache-2.0 | The Python API and SDK for OTLP telemetry. |
| OpenTelemetry Operator | deploys |
Apache-2.0 | A Kubernetes operator that manages Collector deployments and injects auto-instrumentation into workloads. |
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
