otel-collector

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 start

Minimal working configuration: OTLP receiver → memory limiter → OTLP/gRPC exporter to Dash0.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 400
    spike_limit_mib: 100

exporters:
  otlp:
    endpoint: ingress.eu-west-1.aws.dash0.com:4317
    headers:
      Authorization: "Bearer ${env:DASH0_TOKEN}"
    sending_queue:
      enabled: true
      storage: file_storage

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter]
      exporters: [otlp]

See exporters for full authentication and queue configuration, and processors for adding resource detection.

Configuration workflow

1. Write config — define receivers, processors, and exporters; wire them in service.pipelines.
2. Validate locally — run otelcol validate --config=config.yaml to catch structural errors before deployment.
3. Deploy — choose a deployment method from the deployment rule (Helm, Operator, raw manifests, or Docker Compose).
4. Verify — add the debug exporter to a pipeline temporarily and inspect stdout to confirm telemetry is flowing; then remove it before going to production.

Quick reference

Official documentation

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