OpenTelemetry Collector configuration guide

Expert guidance for configuring and deploying the OpenTelemetry Collector to receive, process, and export telemetry.

Rules

Key principles

• Processor ordering matters. Place memory_limiter first in every pipeline. Use the exporter's sending_queue with file_storage instead of the batch processor. Incorrect ordering causes memory exhaustion or data loss.
• One pipeline per signal type. Define separate pipelines for traces, metrics, and logs. Mixing signals in a single pipeline breaks processing and causes runtime errors.
• Every declared component must appear in a pipeline. The Collector rejects configurations that declare receivers, processors, or exporters not referenced by any pipeline.
• Consistent resource enrichment across pipelines. Apply processors that enrich resource attributes like resourcedetection and k8sattributes to every signal pipeline (traces, metrics, and logs), not just one. If one pipeline enriches telemetry with k8s.namespace.name or host.name but another does not, correlation between signals is compromised by incomplete metadata.
• Memory safety is non-negotiable. Always configure memory_limiter in production. Without it, a burst of telemetry can cause the Collector to OOM and crash.

Quick reference

Official documentation

• OpenTelemetry Collector documentation
• Collector configuration
• Collector contrib components
• Dash0 Integration Hub