Technique
Schéma animé : le pipeline du Collector OpenTelemetry
Pour : ingénieurs et SRE · architectesPrérequis : Savoir à quoi sert un Collector OpenTelemetry.
Un OpenTelemetry Collector reçoit les signaux des applications et les envoie aux stockages. Entre les deux, une chaîne de processeurs décide de ce qui est gardé, transformé ou écarté. C’est le dernier endroit où vous maîtrisez la donnée avant qu’elle devienne une ligne de facture, une donnée personnelle exposée ou une preuve d’audit. Ci-dessous, chaque point est un signal : couleur selon le type, lettre selon ce qu’il contient. Cliquez sur un processeur pour le désactiver.
Cliquez sur un processeur (ou Tab puis Entrée) pour le désactiver.
Configuration du Collector
Ordre recommandé : memory_limiter en premier ; filtrage et expurgation tôt, pour que rien de sensible ni d'inutile ne traverse la suite ; tail_sampling après l'expurgation ; batch en dernier, juste avant l'export, ou, à la place, le regroupement dans l'exportateur (sending_queue.batch).
Ce qui arrive dans les stockages
| Destination | Reçus | Bruit | Sensibles | Erreurs |
|---|
Simulation illustrative : proportions de signaux, échantillonnage à 10 % et seuil mémoire sont des hypothèses. Les signaux refusés par memory_limiter sont en réalité réessayés par l'émetteur, dans la limite de sa propre file d'attente.
À essayer
Section intitulée « À essayer »- Désactivez
filter: les points marqués H (health checks) et D (logs de debug) atteignent Tempo et VictoriaLogs. La colonne « Bruit » du tableau grimpe et le volume stocké augmente sans aucun gain de diagnostic. - Désactivez
transform: les adresses e-mail (@) arrivent en clair et les métriques gardent leur labeluser_id(U). Le compteur de données sensibles exposées passe au rouge. Notez aussi queuser_idsur une métrique fait exploser la cardinalité : voir le simulateur de cardinalité. - Désactivez
memory_limiter, puis cliquez sur « Pic de trafic » : la mémoire du Collector dépasse sa capacité, il est tué (OOM) et tous les signaux en vol sont perdus. Réactivez-le et refaites le pic : le Collector refuse une partie des envois, que les émetteurs réessaient, mais il reste debout. - Désactivez
tail_sampling, puisrouting: sans échantillonnage, toutes les traces nominales sont stockées alors que les erreurs étaient déjà toutes conservées ; sans routage, les logs d’audit (A) restent dans le stockage chaud, à rétention courte et le taux « Logs d’audit au froid » tombe à zéro.
L’ordre compte
Section intitulée « L’ordre compte »Les processeurs s’exécutent dans l’ordre où ils sont listés dans service.pipelines, pas dans l’ordre de la section processors. Quatre règles à retenir :
memory_limiteren premier. Il doit pouvoir refuser une donnée avant que le Collector ait dépensé de la mémoire pour la traiter.- Filtrage et expurgation tôt. Ce qui est écarté tôt ne coûte rien plus loin et aucune donnée sensible ne doit traverser l’échantillonnage, le regroupement ou un exportateur.
tail_samplingaprès l’expurgation. La décision est prise sur la trace complète (toutes les erreurs, une fraction du nominal). Elle suppose que tous les spans d’une trace arrivent au même Collector, d’où un exportateurloadbalancingen amont dès qu’il y a plusieurs instances.batchen dernier, juste avant l’export : regrouper des données qui seront ensuite écartées est du travail perdu. L’alternative est de regrouper dans l’exportateur lui-même (sending_queueavecbatch: {}, désactivé par défaut) : c’est la direction prise par le projet pour remplacer le processeur (proposition de dépréciation), mais au 2 octobre 2026 le processeurbatchreste au statut bêta et n’est pas formellement déprécié.
Le routage vers le stockage froid passe par le connecteur routing : l’ancien processeur routing a été retiré au profit du connecteur. La syntaxe exacte de sa table de routage a évolué selon les versions du Collector contrib : la configuration affichée suit la v0.162 (condition OTTL préfixée, log.attributes[...], sans champ context) ; vérifiez la documentation de votre version avant de la reprendre. L’exportateur awss3 vise ici un stockage compatible S3 hors AWS, d’où endpoint et s3_force_path_style.
Ce qu’il faut mesurer en vrai
Section intitulée « Ce qu’il faut mesurer en vrai »Le Collector s’observe lui-même : il expose ses propres métriques (par défaut au format Prometheus sur le port 8888, configurable dans service.telemetry). À suivre :
| Question | Métrique interne du Collector (préfixe otelcol_) |
|---|---|
| Combien de signaux entrent ? | receiver_accepted_spans, receiver_accepted_log_records, receiver_accepted_metric_points |
| Combien sont refusés à l’entrée ? | receiver_refused_* : refus de memory_limiter ou d’un exportateur saturé |
| Combien sortent, combien échouent ? | exporter_sent_*, exporter_send_failed_* |
| La file d’export sature-t-elle ? | exporter_queue_size rapporté à exporter_queue_capacity |
| Le Collector manque-t-il de mémoire ? | process_memory_rss, process_runtime_heap_alloc_bytes et les redémarrages du conteneur côté Kubernetes |
Les noms exacts varient légèrement selon la version (suffixes _total, nouveaux noms de processeurs) : partez de la page /metrics de votre Collector. Pour la donnée sensible, aucune métrique ne remplace un contrôle : une requête régulière dans VictoriaLogs ou Tempo qui cherche un motif d’adresse e-mail et une alerte si elle trouve quelque chose. Pour l’audit, comparez le nombre de logs d’audit émis au nombre d’objets écrits dans le stockage froid.
Pour aller plus loin : le glossaire, la vue technique et côté coût la page business.
Révisé le 2 octobre 2026 : configuration alignée sur le Collector contrib v0.162 (syntaxe trace_conditions et log_conditions du filtre, instructions préfixées de transform, exportateurs otlp_grpc et otlp_http, endpoint du stockage S3) et mention du regroupement dans l’exportateur.