What Is OpenTelemetry? A Complete Guide to Modern Observability

What is OpenTelemetry?

OpenTelemetry merges OpenTracing and OpenCensus, providing a set of APIs and libraries to standardize telemetry data collection and transmission. It offers a vendor‑neutral toolset that can send data to various back‑ends.

OpenTelemetry project consists of the following components:

Promote consistent specifications across projects

Specification‑based APIs and implementations

Language‑specific SDKs (e.g., Java, Python, Go, Erlang)

Exporters to send data to chosen back‑ends

Collectors – vendor‑neutral implementations for processing and exporting telemetry

Terminology

If you are new to OpenTelemetry, you need to understand these terms:

Traces : Record the activity of requests flowing through a distributed system; a trace is a directed acyclic graph of spans.

Spans : A named, time‑based operation within a trace; spans can nest to form a trace tree, with a root span representing end‑to‑end latency.

Metrics : Raw measurement data captured at runtime. Metric instruments include Counter, UpDownCounter, ValueRecorder, SumObserver, UpDownSumObserver, and ValueObserver, each with properties such as synchronous, additive, and monotonic.

Context : Each span contains a span context, a globally unique identifier, and optional correlation context for user‑defined attributes.

Context propagation : Passing context information between services, typically via HTTP headers. OpenTelemetry supports multiple propagation protocols but recommends using a single method in an application.

Benefits of OpenTelemetry

Simplified choice – compatible with both OpenTracing and OpenCensus.

Cross‑platform – supports many languages and back‑ends, providing a vendor‑neutral way to capture and transmit telemetry.

Simplified observability – high‑quality telemetry under a single standard.

How to Use OpenTelemetry

OpenTelemetry APIs and SDKs provide quick‑start guides and documentation. For example, the Java guide shows how to obtain a tracer, create spans, add attributes, and propagate context across spans.

After instrumenting your application, you can use exporters in the OpenTelemetry library to send trace data to observation platforms such as New Relic or other back‑ends.

Metrics and logs specifications are still under development, but once completed they will enable comprehensive telemetry without additional detection code.

OpenTelemetry Architecture Components

OpenTelemetry is designed as a flexible, extensible, cross‑language framework for vendors and observability back‑ends. Its default implementation can be divided into three parts:

OpenTelemetry API

OpenTelemetry SDK (including Tracer pipeline, Meter pipeline, shared Context layer)

Collector

OpenTelemetry API

Developers use the API to instrument code; library authors use it to implement instrumentation. The API does not handle data transport.

The API consists of four parts:

Tracer API

Metrics API

Context API

Semantic conventions

Tracer API

Tracer API supports creating spans, assigning a

traceId

, and optionally timestamps. A tracer tags spans with a name and version, allowing correlation of generated spans with the instrumentation library.

Metric API

Metric API provides various metric instruments such as Counters and Observers. Counters allow aggregation of values, while Observers capture measurements at discrete points (e.g., CPU load, free disk space).

Context API

Context API adds context information to spans and traces that share the same context, supporting standards like W3C Trace Context, Zipkin B3, or New Relic distributed tracing headers. It also enables access to the current context from metric instruments.

Semantic conventions

The API includes a set of semantic conventions for naming spans, attributes, and errors, ensuring consistent instrumentation across languages and providing a uniform APM experience.

OpenTelemetry SDK

The SDK implements the API and contains three components: a Tracer, a Meter, and a shared Context layer.

Tracer pipeline

When configuring the SDK, you associate one or more

SpanProcessor

s with the Tracer pipeline. SpanProcessors observe span lifecycles and forward completed spans to a

SpanExporter

. The SDK includes a simple SpanProcessor that directly forwards spans to an exporter. It also provides a batch processor that groups spans before export, and custom SpanProcessor implementations can add bespoke behavior, such as exporting “in‑progress” spans.

Meter pipeline

The Meter pipeline creates and maintains metric instruments (Counters, Observers, etc.). By default, Counters aggregate by summing values, while Observers aggregate the last recorded value. All instruments eventually export data via a

MetricExporter

. Exporters can be push‑based (periodically sending data) or pull‑based (allowing back‑ends to request data). Examples include New Relic (push) and Prometheus (pull).

shared Context layer

The shared Context layer sits between the Tracer and Meter pipelines, allowing metrics to be recorded within the active span context. Propagators can customize context propagation, with the SDK providing a W3C Trace Context implementation and optional support for Zipkin B3.

Collector

The OpenTelemetry Collector is a vendor‑neutral implementation that receives, processes, and exports telemetry data, eliminating the need for each back‑end to implement its own data format (e.g., Jaeger, Prometheus). It simplifies multi‑backend support and reduces operational overhead.