[Artículo] Conectores, extensiones y observabilidad del Collector

1. Les connecteurs #

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

Principe #

Connecteur spanmetrics — Les métriques RED (débit, erreurs, durée) sont calculées à partir de 100 % des spans, avant l'échantillonnage.

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 #

Connecteur	Rôle
`spanmetrics`	calcule débit, erreurs et durées (histogrammes) par service et opération à partir des spans
`servicegraph`	produit les métriques de la carte des dépendances entre services
`count`	compte des spans, logs ou points de métrique répondant à une condition OTTL
`routing`	envoie les données vers des pipelines différents selon un attribut (locataire, environnement)
`failover`	bascule vers un pipeline de secours si le principal échoue
`forward`	relie simplement deux pipelines du même type

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 #

Extension	Usage
`health_check`	point de santé HTTP pour les sondes Kubernetes et les répartiteurs de charge
`pprof`	profilage du Collector lui-même
`zpages`	pages de diagnostic en direct (pipelines, spans récents)
`file_storage`	stockage sur disque pour la file d'attente persistante et les positions de lecture des fichiers
`bearertokenauth`, `oauth2client`, `basicauth`	authentification auprès des backends ou des clients
`opamp`	pilotage à distance du Collector (voir Bindplane)

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 ?

Métrique	Signale
`otelcol_receiver_accepted_spans` / `_refused_spans`	données acceptées ou refusées à l'entrée
`otelcol_processor_dropped_*`, refus du `memory_limiter`	données perdues par manque de mémoire
`otelcol_exporter_sent_` / `_send_failed_`	envois réussis ou en échec vers le backend
`otelcol_exporter_queue_size` / `_queue_capacity`	file d'attente qui se remplit : backend trop lent ou injoignable

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 #

Distribution	Contenu
`otelcol` (core)	composants essentiels, maintenus par le projet
`otelcol-contrib`	des centaines de composants communautaires : idéal pour tester
`otelcol-k8s`	sélection adaptée à Kubernetes
Distributions éditeurs	Grafana Alloy, Bindplane BDOT, Splunk, Elastic EDOT, AWS ADOT…

# 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.

Conectores, extensiones y observabilidad del Collector