Guide de configuration OpenTelemetry Collector

Conseils d'expert pour configurer et déployer le OpenTelemetry Collector afin de recevoir, traiter et exporter la télémétrie.

Rules

Rule	Description
receivers	Receivers — OTLP, Prometheus, filelog, hostmetrics
exporters	Exporters — OTLP/gRPC vers Dash0, debug, authentification
processors	Processors — memory limiter, resource detection, ordering, sending queue
pipelines	Pipelines — service section, per-signal configuration, connectors
deployment	Deployment — agent vs gateway patterns, deployment method selection
dash0-operator	Dash0 Kubernetes Operator — automated instrumentation, Collector management, Dash0 export
collector-helm-chart	Collector Helm chart — presets, modes, image selection
opentelemetry-operator	OpenTelemetry Operator — Collector CRD, auto-instrumentation, sidecar
raw-manifests	Raw Kubernetes manifests — DaemonSet, Deployment, RBAC, Docker Compose
sampling	Sampling — head, tail, load balancing
red-metrics	RED metrics — span-derived request rate, error rate, duration histograms
custom-distributions	Custom distributions — building a stripped-down Collector binary with OCB

Principes clés

L'ordre des processors est important. Placez memory_limiter en premier dans chaque pipeline. Utilisez sending_queue avec file_storage de l'exporter au lieu du processor batch. Un ordre incorrect entraîne l'épuisement de la mémoire ou la perte de données.
Un pipeline par type de signal. Définissez des pipelines séparés pour traces, metrics et logs. Mélanger les signaux dans un seul pipeline brise le traitement et provoque des erreurs à l'exécution.
Chaque composant déclaré doit apparaître dans un pipeline. Le Collector rejette les configurations qui déclarent des receivers, processors ou exporters non référencés par un pipeline.
Enrichissement des ressources cohérent dans tous les pipelines. Appliquez les processors qui enrichissent les attributs de ressource comme resourcedetection et k8sattributes à chaque pipeline de signal (traces, metrics et logs), pas seulement à un. Si un pipeline enrichit la télémétrie avec k8s.namespace.name ou host.name mais qu'un autre ne le fait pas, la corrélation entre les signaux est compromise par des métadonnées incomplètes.
La sécurité mémoire est non-négociable. Configurez toujours memory_limiter en production. Sans cela, une rafale de télémétrie peut faire que le Collector soit victime d'un OOM et plante.

Démarrage rapide

Configuration minimale fonctionnelle : OTLP receiver → memory limiter → OTLP/gRPC exporter vers 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]

Consultez exporters pour la configuration complète de l'authentification et de la queue, et processors pour ajouter la resource detection.

Workflow de configuration

Écrire la config — définissez receivers, processors et exporters ; câblez-les dans service.pipelines.
Valider localement — exécutez otelcol validate --config=config.yaml pour détecter les erreurs structurelles avant le déploiement.
Déployer — choisissez une méthode de déploiement à partir de la rule deployment (Helm, Operator, raw manifests ou Docker Compose).
Vérifier — ajoutez temporairement l'exporter debug à un pipeline et inspectez stdout pour confirmer que la télémétrie circule ; supprimez-le ensuite avant d'aller en production.

Référence rapide

De quoi avez-vous besoin ?	Rule
Accepter la télémétrie OTLP des applications	receivers
Scraper les endpoints Prometheus	receivers
Collecter les fichiers log ou les host metrics	receivers
Envoyer la télémétrie vers Dash0	exporters
Configurer les retry, queue ou compression	exporters
Définir l'ordre des processors	processors
Ajouter les métadonnées Kubernetes ou cloud	processors
Câbler receivers → processors → exporters	pipelines
Configuration complète fonctionnelle	pipelines
Valider le pipeline avec l'exporter debug	collector-helm-chart, opentelemetry-operator, raw-manifests, ou dash0-operator
Déployer en tant que DaemonSet ou Deployment	raw-manifests
Déployer avec Helm	collector-helm-chart
Déployer avec l'OTel Operator	opentelemetry-operator
Déployer avec l'Operator Dash0	dash0-operator
Auto-instrumenter les applications dans Kubernetes	opentelemetry-operator ou dash0-operator
Développement local avec Docker Compose	raw-manifests
Réduire le volume de traces	sampling
Garder les erreurs et les traces lentes, supprimer le reste	sampling
Expurger les données sensibles dans le pipeline	processors
Générer les RED metrics à partir des traces	red-metrics
Construire un binaire Collector personnalisé	custom-distributions

otel-collector