OpenTelemetry (often shortened to OTel) is a vendor-neutral, open-source collection of APIs, SDKs, and tools for generating, collecting, and exporting telemetry data — traces, metrics, and logs — from your applications and infrastructure.
What it is
OpenTelemetry is a Cloud Native Computing Foundation (CNCF) project — currently its second most active project after Kubernetes. It defines a common specification for how telemetry should be generated and shaped, and ships language-specific implementations (SDKs) that follow that spec for Java, Python, Go, JavaScript/Node.js, .NET, Ruby, PHP, Rust, C++, Swift, and Erlang/Elixir, among others.
Concretely, OpenTelemetry gives you four things:
- A specification — the data model and semantics that every signal (trace, metric, log) must follow, so telemetry means the same thing regardless of language or backend.
- APIs — the interfaces your code calls to create spans, record metrics, and emit logs. Stable across SDK versions.
- SDKs — the reference implementations that process and export the data the API produces (sampling, batching, resource attribution).
- The Collector — a standalone binary that receives, processes, and exports telemetry, decoupling your app from any specific backend.
A brief history
OpenTelemetry was formed in 2019 by merging two earlier, competing CNCF projects: OpenTracing (distributed tracing) and OpenCensus (Google's stats + tracing library). Both had overlapping goals and incompatible APIs, which fragmented the ecosystem — instrumentation libraries had to pick one or the other, and vendors had to support both. Merging them into a single project meant one API surface, one set of semantic conventions, and one wire protocol that every vendor could target.
Before OpenTelemetry, switching observability vendors often meant rewriting instrumentation. OTel decouples "how you instrument" from "where the data goes" — you change an exporter config, not application code.
What it is not
This trips up almost everyone new to the project, so it's worth stating plainly:
| OpenTelemetry is | OpenTelemetry is not |
|---|---|
| An instrumentation and data-collection standard | A storage backend or database |
| A way to generate and ship telemetry | A dashboard, alerting, or visualization tool |
| Vendor-neutral by design | Owned or controlled by any single vendor |
| A wire protocol (OTLP) plus SDKs | A replacement for Jaeger, Prometheus, or Grafana |
You still need a backend — Jaeger or Tempo for traces, Prometheus or Mimir for metrics, Loki or Elasticsearch for logs — or a commercial observability vendor. OpenTelemetry just makes sure the data getting to that backend is generated in a consistent, portable way.
Why it matters
- No vendor lock-in. Instrument once with the OTel API; swap the backend by changing an exporter, not your code.
- One correlated view. Traces, metrics, and logs share the same resource attributes (service name, version, environment) so they can be correlated in a single backend.
- Ecosystem-wide adoption. Most observability vendors (Datadog, Honeycomb, New Relic, Grafana, Splunk, Dynatrace, and more) accept OTLP natively — OpenTelemetry has effectively become the industry's common telemetry format.
- Auto-instrumentation. Many popular frameworks and libraries ship OTel instrumentation out of the box, so you get useful traces before writing a single manual span.
The moving parts, at a glance
You'll meet each of these in depth in later guides — for now, just recognize the names:
| Piece | Role |
|---|---|
| API | What you code against — stable interfaces for creating spans, metrics, and logs. |
| SDK | The implementation behind the API — processes, batches, and samples telemetry. |
| Instrumentation | Code (auto or manual) that calls the API to produce telemetry. |
| OTLP | OpenTelemetry Protocol — the wire format used to ship telemetry between processes. |
| Collector | A standalone process that receives, transforms, and routes telemetry to one or more backends. |
OpenTelemetry standardizes how telemetry is produced and transported. It deliberately stays out of the business of storing or visualizing that data — that's still your backend's job.