Le cœur de la gestion des flux de télémétrie évolue dans l’OpenTelemetry Collector. Le package exporterhelper, selon github.com, fournit désormais des implémentations réutilisables pour les exportateurs, intégrant des fonctionnalités essentielles comme la mise en file d’attente, le regroupement (batching), la gestion des timeouts et les mécanismes de nouvelle tentative (retries).

Ce mouvement marque une transition notable : la logique autrefois gérée par un composant distinct, le processeur batch, est progressivement absorbée par les exportateurs eux-mêmes. OpenTelemetry a entamé ce processus de dépréciation du processeur batch central, en faveur d’un exporter-level batching qui devient par défaut dans la plupart des exportateurs à partir de la version 0.171.0, prévue pour février 2027 (OpenTelemetry, 2026-11-11).

Ce changement d’architecture répondait à des besoins exprimés par la communauté : il fallait plus de contrôle sur les limites de taille en octets, sur la concurrence, et sur la propagation des erreurs. Le vieux processeur batch souffrait d’une queue interne trop rigide, sans support configurable pour la persistance des données ou la gestion avancée de la concurrence (OpenTelemetry, 2026-11-11).

Les mécanismes de gestion de flux en détail

Avec cette intégration, les exportateurs gèrent désormais plus finement le cycle de vie des données. La file d’attente (sending queue) permet de définir une capacité maximale, mesurée soit par le nombre de requêtes, soit par le nombre d’éléments individuels (spans, métriques, logs), soit par la taille en octets. Par exemple, on peut configurer une file d’attente pour accepter 1 000 requêtes, avec un mécanisme de backpressure qui peut soit rejeter immédiatement les données si la file est pleine, soit bloquer l’appelant jusqu’à ce qu’un espace se libère.

Le processus est sophistiqué. Avant que les données n’atteignent l’exportateur final, elles passent par cette file d’attente, puis, si le regroupement est activé, elles sont combinées ou divisées. Il est possible, via la configuration, de définir des stratégies de partitionnement basées sur des métadonnées du client, ce qui est crucial pour les environnements multi-locataires, permettant par exemple de regrouper les données de chaque client séparément. Pour cela, il faut que les récepteurs soient configurés avec include_metadata: true (Source 2).

Pérenniser les données ou les perdre

Un point critique concerne la durabilité. Par défaut, la file d’attente fonctionne en mémoire, ce qui signifie qu’une interruption du Collector entraînerait la perte des données mises en tampon. Pour pallier cela, la fonctionnalité de queue persistante est disponible. En spécifiant une extension de stockage, comme filestorage, les données sont sérialisées et écrites sur le disque. Ainsi, si l’instance s’arrête, elle reprend l’exportation à partir des données sauvegardées.

Néanmoins, il faut noter une contrainte : lorsque la persistance est activée, le paramètre wait_for_result ne peut plus être utilisé, car le cycle de lecture depuis le disque modifie le comportement de réponse au client (Source 2). Bien que le comportement par défaut tende vers une admission immédiate de la requête sans attendre le résultat, l’utilisateur conserve des options fines pour ajuster ces comportements complexes.

Les configurations modernes offrent une granularité impressionnante. Celle-ci couvre des aspects variés, allant des intervalles de nouvelle tentative (tels que initial_interval et max_interval) aux limites de taille de lot (min_size, max_size), sans oublier le temps d’inactivité des partitions (idle_timeout).

Sources

• opentelemetry-collector/exporter/exporterhelper/README.md at 302c933caa8c66f7ebf35ea42238b261bc3e5fc6 ·…, github.com
• opentelemetry-collector/processor/queuebatchprocessor/README.md at 302c933caa8c66f7ebf35ea42238b261bc3e5fc6 ·…, github.com
• Deprecating the Collector Batch Processor, OpenTelemetry, 11 novembre 2026 (contenu sous licence CC BY 4.0)