Connecteurs, extensions et observabilité du Collector

1. Les connecteurs #

Faire passer des données d'un pipeline à un autre.

Principe #

Un connecteur est déclaré comme exportateur d'un pipeline et comme receiver d'un autre. Il permet de transformer un signal en un autre, de router ou de dupliquer des données.

Les plus utiles #

connectors:
  spanmetrics:
    histogram: { explicit: { buckets: [5ms, 25ms, 100ms, 250ms, 1s, 5s] } }
    dimensions: [{ name: http.request.method }, { name: http.response.status_code }]
  routing:
    default_pipelines: [logs/standard]
    table:
      - condition: resource.attributes["tenant"] == "premium"
        pipelines: [logs/premium]
service:
  pipelines:
    traces:          { receivers: [otlp], processors: [batch], exporters: [otlp/tempo, spanmetrics] }
    metrics/spans:   { receivers: [spanmetrics], exporters: [prometheusremotewrite] }

Bonne Pratique : Placez spanmetrics avant tout échantillonnage par la queue (tail sampling) : les métriques restent exactes même si vous ne gardez que 10 % des traces.

2. Les extensions #

Ce qui n'est pas dans le flux de données.

Panorama #

extensions:
  health_check: { endpoint: 0.0.0.0:13133 }
  zpages: { endpoint: 0.0.0.0:55679 }
  file_storage: { directory: /var/lib/otelcol/queue }
exporters:
  otlp/backend:
    endpoint: backend:4317
    sending_queue: { enabled: true, storage: file_storage }   # survit à un redémarrage
service:
  extensions: [health_check, zpages, file_storage]

3. Observer le Collector #

Il faut superviser le superviseur.

Télémétrie interne #

Le Collector expose ses propres métriques (par défaut au format Prometheus sur le port 8888) et peut envoyer ses logs et traces internes en OTLP. Trois questions à surveiller : reçoit-il ? perd-il ? sature-t-il ?

service:
  telemetry:
    logs: { level: info }
    metrics:
      level: detailed
      readers:
        - pull: { exporter: { prometheus: { host: 0.0.0.0, port: 8888 } } }

Erreur Courante : Une alerte sur otelcol_exporter_send_failed_* et sur le remplissage de la file vaut mieux que de découvrir un trou de plusieurs heures dans les traces pendant un incident.

4. Distributions et Collector sur mesure #

Ne livrer que les composants utiles.

Choisir #

# builder-config.yaml pour ocb (OpenTelemetry Collector Builder)
dist: { name: otelcol-maison, output_path: ./dist }
receivers:  [{ gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.115.0 }]
processors: [{ gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.115.0 }]
exporters:  [{ gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.115.0 }]

Bonne Pratique : En production, construisez une distribution avec ocb qui ne contient que vos composants : binaire plus petit, surface d'attaque réduite, mises à jour maîtrisées. Alignez les numéros de version de tous les modules.