OpenTelemetry Collector

The OpenTelemetry Collector (OTel Collector) is a standalone service that receives telemetry, processes it and sends it to one or more backends. It decouples applications from observability vendors. Apps send data to the Collector over OTLP, and the Collector handles batching, filtering, enrichment, sampling and export in one place.

How it works

A Collector config defines pipelines for traces, metrics and logs. Each pipeline has three stages:

1. Receivers accept data, for example OTLP on port 4317.

2. Processors change it, for example memory_limiter, batch, k8sattributes or tail_sampling.

3. Exporters send it to backends.

On Kubernetes, a common pattern runs an agent Collector on every node as a DaemonSet and a gateway Collector as a central Deployment. Processor order matters. Placing memory_limiter first stops the Collector from running out of memory under load.

Why it matters in production

The Collector is where telemetry cost and quality are controlled. A wrong processor order, missing memory limits or high-cardinality attributes can drop data during an incident or multiply your observability bill.

See also

• OpenTelemetry

• Trace sampling

• Cardinality

• Distributed tracing

On the One2N blog

• The gotchas of OTEL collector processors for effective observability in K8s

• A pragmatic guide to get started with OpenTelemetry

References

1. OpenTelemetry Collector (official documentation)