What is the OpenTelemetry Collector?

The OpenTelemetry Collector is the agent and pipeline component of the OpenTelemetry project: a single vendor-neutral binary that receives telemetry in dozens of formats, processes it in flight, and exports it to any backend. It replaces per-vendor agent sprawl with one configurable telemetry pipeline.

Architecture: receivers, processors, exporters

A Collector configuration wires three component types into pipelines, per signal:

• Receivers ingest data: OTLP, Prometheus scrape, filelog (tailing files), syslog, Kafka, Jaeger/Zipkin, host metrics, and hundreds more in the contrib distribution
• Processors transform it: batching, memory limiting, attribute editing, Kubernetes metadata enrichment, filtering, redaction, tail-based sampling
• Exporters send it onward: OTLP to your backend, plus format-specific exporters for interoperability

One Collector can run many pipelines — e.g., logs filtered and shipped to one destination while metrics fan out to two.

Why teams run a Collector

• Decoupling — applications export generic OTLP; backend choice becomes Collector config, not code
• Cost control — drop noise and sample traces before paying ingest fees
• Enrichment — Kubernetes attributes, resource detection, GeoIP applied centrally and consistently
• Resilience — buffering, retries, and backpressure absorb backend hiccups
• Consolidation — replaces separate logging, metrics, and tracing agents with one process

Deployment patterns

The standard Kubernetes setup is a DaemonSet agent on every node (local logs, host metrics, low-latency OTLP receipt) forwarding to a gateway Deployment (central sampling, transformation, egress). The OpenTelemetry Operator can also manage Collectors and auto-instrumentation injection.

The Collector with OpenObserve

OpenObserve ships Helm-based collector configurations for Kubernetes and accepts Collector output natively over OTLP — point the exporter at your OpenObserve endpoint and logs, metrics, and traces arrive correlated and queryable.