Skip to main content
In this lesson we present a concise, high-level overview of the OpenTelemetry Collector architecture and how telemetry flows through it. Understanding these building blocks will help you design robust, scalable observability pipelines for traces, metrics, and logs. Everything begins with telemetry sources — the origins of your data. Typical examples include:
  • Traces emitted by application instrumentation (e.g., OpenTelemetry SDKs).
  • Metrics scraped from a Prometheus server or exposed by applications.
  • Logs from files, agents, or structured log streams.
The Collector ingests these inputs and moves them through a configurable pipeline where each component performs a focused responsibility.

​
Receivers

Receivers are the Collector’s entry points. They accept data over external protocols and translate it into the Collector’s internal data model. Each signal type (traces, metrics, logs) usually has its own receiver implementations. Common examples include otlp, prometheus, jaeger, and filelog. Key responsibilities:
  • Decode wire formats (gRPC, HTTP, protobuf, text).
  • Perform protocol-specific validation or minimal parsing.
  • Hand data into the Collector’s internal pipeline model.

​
Processors

Processors operate on data after reception but before export. They refine, enrich, and reduce data volumes to prepare telemetry for backends. Typical processor tasks:
  • Batching: group items to increase throughput and reduce exporter load.
  • Filtering and routing: drop or route data based on attributes.
  • Transformation / enrichment: add or rewrite attributes, map resource information.
  • Sampling: keep a representative subset of spans to control costs.
Processor order matters. Place sampling before batch when you need to avoid batching sampled-out items, and apply resource/attributes processors early if later processors rely on those attributes.

​
Exporters

Exporters convert the Collector’s internal model into backend-specific wire formats and transmit data over HTTP, gRPC, or other protocols. Examples include exporters for otlp, prometheus, logging, and commercial backends. Exporter responsibilities:
  • Marshal data to the target format (JSON, protobuf).
  • Manage network communication, retries, and timeouts.
  • Optionally implement buffering or queuing logic.

​
Pipelines and Service

Each signal type (traces, metrics, logs) runs in its own pipeline configured under the Collector’s service section. A pipeline executes components in sequence: receiver -> processor(s) -> exporter This modular architecture lets you configure independent processing paths for each signal type and tailor behavior to different backends. Example pipeline configuration (YAML):
Each pipeline is signal-specific (traces, metrics, logs). Receivers translate protocols, processors modify or enrich data, and exporters deliver processed telemetry to your chosen backends.

​
Connectors

Connectors bridge data between pipelines or transform one signal into another. Use cases include:
  • Deriving metrics from traces (e.g., counting specific trace events).
  • Routing logs into metrics or traces for correlation.
  • Forwarding data from one pipeline to another without touching the original instrumentation.
Connectors enable cross-signal workflows and richer observability without changing application code.

​
Extensions

Extensions run outside the main signal pipelines and add operational capabilities to the Collector process itself. Examples:
  • Health checks and readiness probes.
  • zPages for debugging and insight into internal state.
  • Authentication, TLS termination, and observability endpoints.
The image illustrates the architecture of an OpenTelemetry Collector, detailing how it processes traces, metrics, and logs from various sources to different backends through receivers, processors, and exporters. It also includes service extensions like health checks and zPages.

​
Putting it all together

Telemetry enters via receivers, flows through configured processors inside a pipeline, and exits through exporters to one or more backends. Connectors let you bridge pipelines when you need cross-signal conversions, while extensions provide operational and administrative capabilities for the Collector process itself. This architecture allows you to compose multiple independent pipelines and components to match your deployment, scaling, and observability requirements.

​
Component Summary

Component TypePurposeExamples
ReceiversIngest and translate external protocols into the Collector modelotlp, prometheus, jaeger, filelog
ProcessorsEnrich, filter, sample, and batch telemetrybatch, attributes, tail_sampling, memory_limiter
ExportersSend processed telemetry to backendsotlp, prometheus_remote_write, logging
ConnectorsBridge or convert between signal pipelinesmetrics_from_traces, logs_to_metrics
ExtensionsOperational endpoints and management featureshealth_check, zpages, pprof

​
Best Practices

  • Design pipelines around signal types to keep configuration clear and maintainable.
  • Use batching and memory-limiting processors to avoid spikes in exporter load.
  • Apply sampling strategically to control cost while preserving signal fidelity.
  • Monitor the Collector (using extensions like zPages or Prometheus metrics) to detect backpressure and resource issues.
Start small: configure a single pipeline, validate end-to-end telemetry flow, then iterate with processors and exporters as your needs grow.

Watch Video