What Is OpenTelemetry? Traces, Metrics, and Logs

OpenTelemetry (often shortened to OTel) is an open-source collection of APIs, SDKs, and tools for generating and exporting telemetry data — traces, metrics, and logs — from an application. It doesn’t store or visualize that data itself; it standardizes how the data is produced so it can be sent to whatever backend you choose, without rewriting instrumentation every time you switch vendors.

Before OpenTelemetry, instrumenting an app usually meant picking a vendor’s proprietary SDK and baking it into the codebase. Switching from one tracing backend to another meant ripping out and replacing instrumentation across every service. OpenTelemetry breaks that coupling by putting a vendor-neutral layer between the application code and the observability backend.

The three signal types

OpenTelemetry standardizes three kinds of telemetry, sometimes called the three pillars — see logs vs. metrics vs. traces for a broader comparison of what each is good at:

• Traces — the path a single request takes through a system, broken into spans. A span records an operation’s name, start and end time, and any attributes or errors attached to it. Spans nest to show, for example, that an API call triggered a database query which triggered a cache lookup.
• Metrics — numeric measurements aggregated over time, like request counts, latency histograms, or queue depth. Cheap to store and query, but they tell you that something is wrong, not why.
• Logs — discrete, timestamped event records. The most granular signal, and the one most likely to contain the specific detail (an exception stack trace, a malformed payload) that explains a failure.

Correlating all three — jumping from a slow trace span to the metric that first flagged it to the log line that names the exception — is the point of instrumenting with one standard instead of three separate ones.

How instrumentation works

OpenTelemetry has two ways to get telemetry out of an application:

1. Automatic instrumentation — an agent or library that hooks into common frameworks (HTTP servers, database drivers, RPC clients) and emits spans and metrics without touching application code. This is the fastest way to get baseline visibility into a service.
2. Manual instrumentation — using the OpenTelemetry SDK directly in code to create custom spans, record specific attributes, or emit business metrics that automatic instrumentation can’t infer, such as “checkout total” or “user tier.”

Most real deployments use both: automatic instrumentation for the framework and library boundaries, manual instrumentation for the parts of the business logic worth tracing individually.

The Collector

Rather than having every service export telemetry directly to a backend, OpenTelemetry defines a separate component called the Collector — a standalone process that receives telemetry over its OTLP (OpenTelemetry Protocol), processes it (batching, filtering, redacting sensitive fields), and exports it to one or more backends.

Running a Collector, typically as a sidecar or a cluster-wide daemon, decouples applications from the specific backend entirely. An application only needs to know how to talk OTLP to a local Collector endpoint; the Collector’s configuration decides where the data actually ends up — a self-hosted tracing store, a managed SaaS platform, or several destinations at once for migration or fan-out.

Why vendor neutrality matters

The practical benefit of OpenTelemetry is that instrumentation becomes a durable investment rather than a vendor lock-in point. A team can:

• Switch observability vendors by reconfiguring the Collector’s exporters, not by re-instrumenting every service.
• Run two backends in parallel during a migration, sending the same data to both.
• Standardize instrumentation across a polyglot fleet, since OpenTelemetry SDKs exist for most major languages and follow the same semantic conventions for naming spans and attributes.

That last point matters more than it sounds. Semantic conventions — agreed-upon names for common attributes like http.method or db.system — mean a trace generated by a Java service and one generated by a Go service look consistent in the same dashboard, which is what makes cross-service correlation possible in microservices architectures at all.

Where it fits with SRE practice

Distributed tracing existed before OpenTelemetry — see distributed tracing explained for the concept on its own — but earlier tracing systems were mostly proprietary or single-vendor. OpenTelemetry absorbed and superseded two earlier projects, OpenTracing and OpenCensus, merging their approaches into one CNCF-governed standard.

For teams practicing site reliability engineering, OpenTelemetry is usually the instrumentation layer underneath whatever SLO dashboards and alerting rules actually get used day to day. The signals it produces feed directly into the metrics that define error budgets and the traces that get pulled up during an incident to find where latency or errors originated.

Getting started practically

Adopting OpenTelemetry incrementally works better than a big-bang rollout:

1. Instrument one service with automatic instrumentation and point it at a Collector.
2. Confirm traces and metrics show up correctly in whatever backend you’re testing.
3. Add manual spans for the handful of operations that matter most to your business logic.
4. Expand to additional services, standardizing span and attribute naming as you go.

The overhead is mostly in the beginning — evaluating the Collector’s processors and exporters, and getting semantic conventions right — rather than in ongoing maintenance, since the whole point is that instrumentation stops needing to change every time the backend does.

The takeaway

OpenTelemetry standardizes how applications produce traces, metrics, and logs, so instrumentation isn’t tied to one vendor’s SDK. Applications emit telemetry over OTLP to a Collector, which processes and routes it to whatever backend you choose — letting you switch tools, run backends in parallel, or standardize telemetry across a polyglot fleet without touching application code each time.