OpenTelemetry Collector configuration guide

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