To appreciate unification, first look at what life is like without it.

Modern software is usually built from many small services that talk to each other over a network. When something goes wrong, such as a page loading slowly, the cause might hide in any one of dozens of places. To investigate, engineers rely on observability, which is the ability to understand what is happening inside a system by looking at the data it produces.

Historically, each kind of data came with its own tooling. A logging product collected log files. A metrics product scraped numbers from endpoints. A tracing product followed requests through services. Each product required its own agent installed on every machine, its own library inside every application, its own data format and its own way of naming things. Teams ended up running three or four parallel systems that did not talk to each other.

The everyday pains of a fragmented setup

flowchart LR
  A["Application"] --> L["Logging agent"] --> LB["Logs backend"]
  A --> M["Metrics agent"] --> MB["Metrics backend"]
  A --> T["Tracing agent"] --> TB["Traces backend"]
        

A pipeline carries data, so it helps to know the kinds of data it carries.

OpenTelemetry calls each kind of observability data a signal. The collective name for all of this data is telemetry, meaning measurements and records that a system sends out about itself. The main signals are described below.

Unified does not mean “one giant program that does everything”. It means shared foundations.

A unified observability pipeline is one in which all your telemetry, whatever its signal type, follows the same standards and shares the same infrastructure from the moment it is created until the moment it reaches its destination. It is unified in several different senses at once, and each of them solves one of the pains from Chapter 1.

flowchart LR
  A["Application with OpenTelemetry SDK"] --> C["OpenTelemetry Collector"]
  C --> B1["Traces backend"]
  C --> B2["Metrics backend"]
  C --> B3["Logs backend"]
  C --> B4["Or one backend for all"]
        

Follow a single measurement from the moment it is born to the moment it is used.

The best way to understand a pipeline is to follow the data. Suppose a customer clicks a button to place an order. Along the way, several pieces of telemetry are produced. Here is the journey in five stages.

sequenceDiagram
  participant App as Application code
  participant SDK as OpenTelemetry SDK
  participant Col as Collector
  participant Back as Backend
  App->>SDK: Span, metric, log
  SDK->>SDK: Add resource info, batch
  SDK->>Col: OTLP export
  Col->>Col: Filter, enrich, batch
  Col->>Back: Export to chosen backends
        

Everything starts with how data is created, and OpenTelemetry offers one consistent way to do it.

Instrumentation means adding the ability to produce telemetry to software. There are two broad ways to do it, and a unified pipeline lets you use both together.

The API and the SDK: two parts with different jobs

Why this split supports unification

Because library authors use the common API, every library that supports OpenTelemetry speaks the same language, whichever backend the application owner chooses. Switching backends then becomes a configuration change rather than a rewrite of instrumentation across hundreds of services.

Data can only be combined if everyone calls the same thing by the same name.

Two layers of description make telemetry from different sources comparable: resources and semantic conventions.

Resources: who produced this data

A resource is a set of attributes that describes the entity producing telemetry, such as the service name, its version, the host and the cloud region. It is attached to every signal from that source. Because traces, metrics and logs from the same service carry the same resource description, a backend can group them together automatically.

Semantic conventions: agreed names for common things

Semantic conventions are the standard names and meanings for attributes that describe common situations, such as an HTTP request, a database call or a message queue operation. Instead of every team inventing its own label for the web address of a request, a convention provides one agreed name used everywhere.

The real prize of unification is being able to jump from one kind of data to the related others.

Having traces, metrics and logs in one place is useful. Having them connected is transformational. Correlation means linking pieces of telemetry that belong to the same event, so that from one you can find the others. OpenTelemetry makes this possible through context.

Trace context: the shared thread

Every request that enters a system is given a trace identifier, a unique code. As the request moves from service to service, the identifier travels with it, usually in the headers of the network call. Each step records a span identifier for itself. This travelling information is called context propagation, and it is what lets separate services contribute to one shared trace.

How the signals link together

flowchart TD
  M["Metric spike: error rate rises"] --> T["Linked example trace"]
  T --> S["Slow span in payment service"]
  S --> L["Log record with the same trace id: card declined by provider"]
        

One protocol can carry every signal, which is what lets the same pipe serve all of them.

OTLP, the OpenTelemetry Protocol, is the standard format and set of rules for sending telemetry from one place to another. It can carry traces, metrics and logs in one consistent design, and it can travel over two common transports: gRPC and HTTP. It is the native language of OpenTelemetry components.

It is not the only language

OTLP is the preferred language, but the world has other established formats. The Collector can receive data in many of them, such as formats used by Jaeger, Zipkin and Prometheus, and convert it. This matters because very few organisations start from nothing. A unified pipeline can absorb existing tools gradually instead of demanding that everything change on one day.

The Collector is where the pipeline becomes a pipeline, with one place to receive, process and export.

The OpenTelemetry Collector is a standalone program that receives telemetry, optionally changes it, and sends it onward. The documentation describes it as a vendor-agnostic way to receive, process and export telemetry, and notes that it removes the need to run and maintain several agents or collectors for different data formats. A single codebase handles traces, metrics and logs.

The building blocks inside the Collector

flowchart LR
  R["Receivers: OTLP, Prometheus, file logs and more"] --> P["Processors: protect, filter, enrich, batch"]
  P --> E["Exporters: one or many backends"]
  P --> C["Connectors: feed another pipeline"]
  C --> P2["Second pipeline"]
        

One pipeline per signal, one shared design

Inside the Collector, each signal travels through its own pipeline, but all pipelines use the same building blocks and are described in the same configuration file. A single receiver can feed all three. The same kinds of processors apply to each. This is the practical meaning of unified processing: one tool, one configuration, one place to apply rules.

The pipeline can be laid out in several shapes, from very simple to very robust.

The Collector documentation describes several deployment patterns. Choosing among them is one of the key design decisions for a unified pipeline, and many teams move from the simplest toward the more capable as they grow.

flowchart LR
  A1["App 1"] --> G1["Agent Collector"]
  A2["App 2"] --> G2["Agent Collector"]
  G1 --> GW["Gateway Collector"]
  G2 --> GW
  GW --> B1["Backend A"]
  GW --> B2["Backend B"]
        

When all data passes through one hub, rules can be written once and applied everywhere.

One of the strongest benefits of a unified pipeline is central policy. Instead of repeating rules inside every application and every tool, you describe them in the Collector. Here are the most common kinds.

When signals share a pipeline, they can also feed each other.

A connector is a Collector component that acts as an exporter at the end of one pipeline and a receiver at the start of another. It makes it possible for data from one signal to produce or influence another. This is a distinctly unified capability, because it needs all signals to live in the same system.

A unified pipeline keeps your instrumentation yours, whichever product receives the data.

OpenTelemetry is a vendor-neutral project, meaning it is not owned by or tied to any single monitoring company. Because instrumentation uses the common API and data leaves through standard exporters, the choice of backend becomes a decision that can be changed later with far less pain than in the past.

What neutrality gives you

flowchart LR
  A["Standard instrumentation"] --> C["Collector"]
  C --> V1["Vendor A"]
  C --> V2["Vendor B"]
  C --> V3["Open-source backend"]
  C --> V4["Archive storage"]
        

A comparison makes the differences concrete.

Five everyday situations show how a unified pipeline helps.

A pipeline that carries everything must itself be trustworthy.

When all telemetry flows through one pipeline, the pipeline becomes critical infrastructure. If it fails, you lose visibility exactly when you may need it most. A few themes are essential in any serious setup.

Monitor the monitor

The Collector produces its own logs and metrics, such as how many items it received, refused and dropped. Make sure these are collected and graphed, and set alerts on refused or dropped data. A pipeline that quietly drops data because it is overloaded is a failure nobody notices unless the pipeline reports on itself.

Unification is a strong idea, but it is not magic, and an honest guide must say so.

Most organisations arrive at a unified pipeline in steps. They begin by sending one signal from one service, then add more signals, then more services, then a Collector, then central policy. At each step, they gain a little more of the benefit, and they can stop whenever the remaining effort outweighs the remaining gain.

These mistakes appear again and again in real projects.

You do not need to build everything at once. Here is a sensible order.

flowchart LR
  A["One service, direct export"] --> B["Add a Collector"]
  B --> C["Connect signals with shared context"]
  C --> D["Central policy at a gateway"]
  D --> E["Many services, one pipeline"]
        

A short list to keep beside you.

Quick answers to the questions beginners ask most often.

No. It is a descriptive phrase for the architecture you get when traces, metrics and logs share OpenTelemetry’s standards, protocol, context and Collector. The Collector’s documentation does list being unified as one of its goals.

No. The unity lies in how data is created, labelled and carried. You can send signals to one backend or to several, and change your mind later.

Not strictly, because applications can export directly. But the Collector provides central processing, central policy and the ability to absorb many formats, so most mature setups include one.

The OpenTelemetry Protocol, the standard format for sending traces, metrics and logs between OpenTelemetry components, available over gRPC and HTTP.

Through shared resource attributes, trace context carried between services, trace identifiers attached to logs, and references from metrics to example traces.

They provide standard names and meanings for common attributes, so that data from different services and tools can be searched and compared consistently.

Yes. The Collector can receive data in many established formats and convert it, so you can migrate gradually and run old and new side by side.

The simplest one that meets your needs. Many teams begin by exporting directly, then add a Collector as an agent or gateway when they need central control.

By filtering noise, sampling routine traces and limiting what is sent, all in one central place, before data reaches backends that charge by volume.

The pipeline becomes critical infrastructure. Protect it with memory limits, several gateway instances, sensible queues, security settings and monitoring of its own health.

No. Maturity varies by signal and by language, and newer signals such as profiles are still developing. Check the status for the languages and signals you use before relying on them.

A unified observability pipeline in OpenTelemetry is not a single product but a way of building: traces, metrics and logs are created with one standard, labelled with one vocabulary, carried in one protocol, linked by shared context, processed in one hub and delivered to whichever backends you choose. This replaces a pile of disconnected tools with a connected system in which you can move from a symptom on a graph to a trace and then to the exact log line, and in which rules for cost and privacy are written once. It is best adopted step by step, with attention to conventions, context propagation, the health of the Collector itself and an honest view of the trade-offs.