What is the OpenTelemetry Collector?
The OpenTelemetry Collector is a vendor-neutral agent that receives, processes, and exports telemetry — a configurable pipeline of receivers, processors, and exporters for logs, metrics, and traces.
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.
Frequently asked questions
Do I need the OpenTelemetry Collector, or can SDKs export directly?
SDKs can export OTLP straight to a backend, which is fine for small setups. A Collector becomes valuable when you want centralized control - filtering and sampling before egress, adding Kubernetes metadata, buffering against backend outages, fanning out to multiple destinations, or collecting host metrics and logs that SDKs don't produce.
What is the difference between the core and contrib distributions?
The core distribution contains a minimal, stable set of components. The contrib distribution adds the long tail - hundreds of receivers, processors, and exporters for specific technologies and vendors. Many teams build a custom distribution with only the components they use, via the OpenTelemetry Collector Builder (OCB).
How is the Collector typically deployed?
Two common patterns, often combined - an agent per host or Kubernetes node (DaemonSet) collecting local telemetry, and a gateway tier (Deployment) providing central processing, sampling, and egress. Small environments can run a single gateway; large ones run both layers.
Related terms
Keep reading
See these concepts in action
OpenObserve unifies logs, metrics, traces, and frontend monitoring in one open-source platform — at a fraction of the cost of legacy tools.