# 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.

Source: https://openobserve.ai/glossary/what-is-opentelemetry-collector/
Published: 2026-07-08
Term: OpenTelemetry Collector
Category: OpenTelemetry
Related terms: what-is-otlp, what-is-telemetry-pipeline, what-is-telemetry

---

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](/glossary/what-is-telemetry-pipeline/).

## Architecture: receivers, processors, exporters

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

- **Receivers** ingest data: [OTLP](/glossary/what-is-otlp/), Prometheus scrape, filelog (tailing files), syslog, Kafka, Jaeger/Zipkin, host metrics, and hundreds more in the [contrib distribution](/blog/opentelemetry-collector-contrib/)
- **Processors** transform it: batching, memory limiting, attribute editing, Kubernetes metadata enrichment, [filtering](/blog/filter-logs-at-source-in-otel-collector/), redaction, tail-based sampling
- **Exporters** send it onward: OTLP to your backend, plus format-specific [exporters](/blog/otel-exporters-introduction/) 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](/kubernetes-monitoring/) and accepts Collector output natively over OTLP - point the exporter at your OpenObserve endpoint and logs, metrics, and traces arrive correlated and queryable.