Observability · standards · devops

What is OpenTelemetry?

By ColdwastUpdated Aug 14, 20269 min read#opentelemetry#observability#devops

A silver laptop open on a dark low table in a living room, its screen filled with a web analytics dashboard: a trend line, a blue cohort grid, a world map and a blue donut chart — A laptop on a low table showing an analytics dashboard - trend line, blue cohort grid, world map and a donut chart, with a grey sofa out of focus behind it. The dashboard is the easy part; what feeds it is the question.

OpenTelemetry is a standard for producing telemetry, not a tool for looking at it. That single sentence resolves most of the confusion around it. You instrument your application once, in a vendor-neutral way, and decide separately where the data goes.

It is a CNCF project, formed in 2019 from the merger of two earlier efforts - OpenTracing and OpenCensus - which had split the same problem between them. The merger is the whole point: before it, choosing an instrumentation library meant choosing a camp.

The problem it exists to solve

Before OpenTelemetry, instrumenting an application meant importing your monitoring vendor's SDK throughout your codebase. Changing vendor meant touching every service that had ever emitted a metric.

That is vendor lock-in expressed as source code, and it is unusually sticky, because the cost of leaving is spread across every team that ever added a span. OpenTelemetry inverts it: the instrumentation belongs to you, the backend is a configuration choice.

The three signals

OpenTelemetry defines three kinds of telemetry, and they answer different questions.

Traces follow a single request across services. A trace is made of spans, each with a start, a duration and a parent, so you can see that a request spent 40 ms in your API and 2 seconds waiting on a database. This is what tells you where time went.

Metrics are aggregated numbers over time: request rate, error count, queue depth, memory in use. They are cheap to store and to graph, and they tell you that something changed, rarely why.

Logs are the familiar timestamped lines. Their addition to OpenTelemetry matters less for the format than for the correlation: a log emitted inside a span can carry that span's identifiers, so a line in a log file leads back to the exact request that produced it.

Used together the division of labour is clear: metrics notice the problem, traces locate it, logs explain it.

A tablet standing on a wooden table showing an analytics dashboard with a traffic-sources pie chart, a world map overlay, a visitors line chart and a content table, with a white cup and a smartphone blurred beside it — A tablet on a wooden desk showing a traffic dashboard: a pie chart splitting direct, search and referral traffic, a world map, and a visitors line reading 2,958. A white cup, a phone and a stylus sit around it, out of focus.

API, SDK, Collector: what each part actually is

Three names come up constantly, and mixing them up is the usual source of confusion.

The API is what your code calls. It is deliberately minimal and does nothing on its own: an application built against the API but without an SDK produces no telemetry and pays almost nothing for the calls. This is what makes it safe for a library author to instrument their library - the decision to collect is left to the application.

The SDK is the implementation you configure: sampling, batching, and which exporters to use. It turns API calls into data that leaves the process.

The Collector is a separate binary that receives telemetry, transforms it and forwards it. It is optional, and it is also the part people end up appreciating most: it lets you change backend, add filtering, drop noisy attributes or fan out to two systems without redeploying your applications.

What OpenTelemetry does not do

It does not store anything, and it does not draw a single graph. There is no OpenTelemetry UI to log into.

You still need a backend - Jaeger, Prometheus, Grafana, or a commercial platform - and that is a deliberate scope decision rather than a gap. It also means adopting OpenTelemetry does not by itself give you observability: it gives you portable data, and you still have to choose where to put it and who reads it at three in the morning.

The second thing worth knowing before adopting it: telemetry has a cost. Traces at full volume on a busy service produce a lot of data, which is why sampling exists and why it deserves thought early rather than after the first bill.

Should you use it?

If you run more than a couple of services, yes - and the argument is portability rather than features. Instrumenting once against a standard means the next backend migration is a configuration change instead of a rewrite.

If you run a single application, the honest answer is that plain logs and a couple of metrics will serve you for a long time. Distributed tracing solves a distributed problem; adopting it before you have one adds moving parts without answering a question you actually have.

The practical starting point for most teams is auto-instrumentation: for several languages, agents can produce useful traces from an unmodified application. It is enough to see whether the data tells you anything before you spend a sprint adding spans by hand.

Independent, community-maintained guide. coldwa.st is a programming-resources site; this article is new, original explanatory writing about OpenTelemetry and is not affiliated with the OpenTelemetry project or the CNCF. The specification evolves and signal stability differs between languages - check the current documentation for your runtime before relying on a detail.

Related reading: What is Docker · What is Kubernetes · What is a message queue