What is the OpenTelemetry Collector and what role does it play?

Think of the OpenTelemetry Collector as a mail sorting facility. Letters (telemetry data) arrive from thousands of homes (services), get sorted, filtered, and routed to the correct destinations (backends). The sorting facility can handle mail from any post office (receiver) and deliver to any carrier (exporter), and you can add processing steps like removing junk mail (filtering) or combining small packages into larger shipments (batching).

The OpenTelemetry Collector is a standalone binary that forms the backbone of most production OpenTelemetry deployments. It is built around three core components: receivers, processors, and exporters, connected through pipelines. Receivers accept telemetry data in various formats. The OTLP receiver handles OpenTelemetry's native protocol, but the Collector also supports Jaeger, Zipkin, Prometheus, and other formats. This means you can migrate from Jaeger to OpenTelemetry incrementally: existing services send Jaeger-format spans to the Collector, which converts and exports them alongside native OTLP data. In a microservices environment with payments-api, checkout-service, and user-auth-service, every service sends its telemetry to the Collector rather than directly to the backend.

Processors sit between receivers and exporters and transform telemetry data in flight. The batch processor groups telemetry into larger payloads to reduce network overhead, which is essential in high-throughput environments. The memory_limiter processor prevents the Collector from consuming too much memory during traffic spikes. The filter processor drops unwanted telemetry, like health check spans that add noise without value. The attributes processor can add, modify, or delete attributes, such as injecting the Kubernetes namespace or removing sensitive data like user email addresses before export. In production at scale, processors are where platform teams implement their telemetry governance policies.

Exporters send processed telemetry to one or more backends. The OTLP exporter sends data to any OTLP-compatible backend like Grafana Tempo, Jaeger, or Datadog. The Prometheus exporter exposes metrics in Prometheus format for scraping. The logging exporter prints telemetry to stdout for debugging. A single Collector instance can export the same data to multiple backends simultaneously: traces to Jaeger for developers, metrics to Prometheus for SREs, and everything to an S3 bucket for long-term storage. This fan-out capability is one of the strongest reasons to use the Collector rather than exporting directly from applications.

The Collector can be deployed in two patterns: as an agent (sidecar or DaemonSet alongside applications) and as a gateway (centralized cluster receiving from multiple agents). In Kubernetes, a common pattern deploys the Collector as a DaemonSet where each node runs an agent that receives telemetry from pods on that node. The agents forward data to a gateway Collector deployment that handles heavy processing, sampling, and export. This two-tier architecture reduces the blast radius of Collector failures and keeps resource-intensive processing off application nodes. For a team running order-processing-service and inventory-sync across a 50-node Kubernetes cluster, the agent handles lightweight batching on each node while the gateway handles tail-based sampling and export to Grafana Cloud.