Les distributions du Collector OpenTelemetry embarquent beaucoup plus de composants que n'en utilise un déploiement donné. Alex Boten (Grafana Labs) s'intéresse ici à un cas précis : les détecteurs de ressources, qui ajoutent automatiquement aux données des attributs sur l'environnement (fournisseur de cloud, conteneur, hôte). Choisir un composant qui sait détecter, comme le processeur de détection de ressources, compile tous les détecteurs, même si vous ne tournez que dans un seul environnement.
Deux moyens sont maintenant décrits. Le premier passe par des étiquettes de compilation omit_detector_*, une par détecteur. Le second, plus court, est disponible dans la version 0.163.1 de ocb (l'outil qui construit un Collector à partir d'un manifeste YAML) : on liste dans le bloc resource.detection.detectors les seuls détecteurs à garder.
Le résultat publié concerne la distribution Kubernetes du projet : 182 Mo avec tous les détecteurs, 147 Mo sans ceux qui ne servent pas, soit environ 20 % de moins et 13 paquets de dépendances en moins. L'auteur y voit aussi une surface d'attaque réduite et moins de modules à suivre quand une faille est annoncée.
Ce que ça change pour un testeur de performance
Peu de choses sur la charge elle-même : l'article ne mesure ni le temps de démarrage ni la mémoire consommée, donc aucun gain n'est annoncé ici. Le sujet intéresse plutôt celui qui prépare un banc d'essai. Si un Collector tourne sur chaque injecteur ou chaque nœud testé, construire soi-même le binaire permet de figer son contenu et sa version, ce qui aide à reproduire une campagne. À notre avis, c'est un point d'hygiène de banc, pas une optimisation à mettre en avant.
Les manifestes de l'article, avec leurs versions, ne sont pas rejoués ici.
Rédigé avec l’aide d’une IA, relu et validé par Philippe Naveau.