Le File Log receiver, le composant du Collector qui lit des fichiers de journaux, enregistre un point de reprise à la fin de chaque cycle de lecture quand une extension de stockage est configurée, pour ne perdre aucune ligne et n'en dupliquer aucune après un redémarrage. Ce point de reprise était écrit en JSON. Depuis la version 0.164.0 de opentelemetry-collector-contrib, il l'est systématiquement en protobuf. L'origine est un signalement d'octobre 2025 : un collecteur Kubernetes consommait nettement plus que Fluent Bit, et le profilage montrait beaucoup de processeur dépensé à encoder du JSON.
Mesures du projet (1 000 fichiers suivis, dix exécutions comparées par benchstat, machine virtuelle partagée de 4 vCPU) :
| Opération (1 000 fichiers) | JSON | Protobuf |
|---|---|---|
| Enregistrement | 15,38 ms | 3,21 ms |
| Relecture | 28,18 ms | 5,01 ms |
| Taille du point de reprise | 1,740 Mio | 1,139 Mio |
Avec un intervalle de lecture de 200 ms (la valeur par défaut), cela fait cinq écritures par seconde. Pour 1 000 fichiers suivis, le projet en déduit environ 77 ms de processeur par seconde consacrés aux points de reprise en JSON, contre 16 ms en protobuf. Il signale un compromis : environ 10 à 13 % d'allocations en plus par enregistrement, pour une mémoire allouée divisée par deux.
Ce que ça change pour un testeur de performance
L'agent de collecte fait partie du système mesuré. Si vos tests produisent beaucoup de journaux, son coût de processeur entre dans vos courbes, et une montée de version qui divise ce poste par cinq, d'après le projet, déplace votre point de référence. Rejouez votre test de base après la mise à jour avant de comparer avec l'ancien. Les ratios viennent d'un banc du projet : le gain chez vous reste à mesurer.
Rédigé avec l’aide d’une IA, relu et validé par Philippe Naveau.