Lors de la KubeCon Europe 2025, éditeurs et usagers de la communauté ont partagé leurs vues sur les avantages et les défauts du framework de collecte de télémétrie. Malgré les turbulences, OpenTelemetry gagne en finesse pour répondre aux besoins des grands comptes.
OpenTelemetry est désormais le deuxième plus gros projet en nombre de contributions au sein de la Cloud Native Computing Foundation (CNCF). Derrière Kubernetes. Et à la tête des donations, il faut compter sur Splunk, mais aussi Datadog, Dynatrace, Elastic, Google, Grafana, Microsoft, New Relic, ServiceNow ou encore Honeycomb.
OpenTelemetry, le deuxième plus gros projet de la CNCF derrière Kubernetes
« Tout le monde a la même importance », assure Stéphane Estevez, conseiller du marché de l’observabilité EMEA chez Splunk.
En clair, la plupart des acteurs importants de l’observabilité s’entendent sur le fait que la collecte de données ne devrait pas être propriétaire. Et les utilisateurs apprécient, eux, la neutralité d’OpenTelemetry (Otel pour les intimes). Le projet open source est perçu comme un moyen de garder le contrôle sur l’envoi de leurs données vers la solution d’observabilité de leur choix, qu’elle soit ouverte ou non.
Pour rappel, OpenTelemetry est « une collection d’API, de SDK et d’outils pour instrumenter, générer, collecter et exporter des données de télémétrie ». Métriques, traces, logs, profiles : Otel peut, en théorie, tous les prendre en charge.
Les éditeurs ont toutefois des approches différentes. « Chez Splunk, nous avons fait le choix d’une instrumentation native avec OpenTelemetry, sans agents propriétaires », répète Stéphane Estevez.
D’autant qu’en général, OpenTelemetry serait moins gourmand en ressources. « les gens ne se rendent pas souvent compte, mais c’est souvent beaucoup plus léger que ces agents propriétaires qui sont souvent énormes, parce qu’ils doivent couvrir tous les cas de figure », relate-t-il.
L’auto-instrumentation n’est pas magique
Depuis près de deux ans, Splunk met l’accent sur l’auto-instrumentation, aussi nommée « Zero Code Instrumentation » dans la distribution open source. « Nous découvrons automatiquement les bases de données et les middlewares, OracleDB, SQL Server, MongoDB, RabbitMQ, NGINX, Redis, Apache Web Server ou encore Apache Kafka », explique le conseiller. « Nos clients peuvent ensuite activer l’instrumentation ».
Pour les solutions tierces non prises en charge, mais bâties sur Linux et Kubernetes, Splunk donne l’accès à un moyen de découvrir d’autres technologies et de déployer un daemon pour installer les bons collecteurs.
Splunk a également travaillé à prendre en charge les langages de programmation, dont Java, .NET et Node.js. « Actuellement, nous nous concentrons sur les langages compilés, dont C++ et Go », explique Stéphane Estevez. Des fonctions d’abord intégrées dans la suite Splunk ; mais elles sont aussi « rendues » à la communauté. « Il peut y avoir des ajustements en fonction de ce que dit la communauté. Mais à aucun moment, on ne veut garder une distribution propriétaire », avance-t-il.
L’auto-instrumentation est également appréciée par la communauté. Dans la version open source du projet, elle est fonctionnelle pour les applications .NET, Java, Node.js, Python et Go. Elle est toutefois légèrement plus complexe à configurer que ce que proposent les éditeurs.
Bien que très flexible, elle n’est toutefois pas sans problème, selon Elena Kovalenko, ingénieure logiciel principale chez Delivery Hero, une entreprise allemande spécialisée dans la livraison de repas. « C’est très facile à utiliser, mais l’auto-instrumentation .NET a généré des spans et des traces avec une cardinalité particulièrement élevée, ce qui a surchargé nos collecteurs [OpenTelemetry] », relate-t-elle, lors d’une session de la KubeCon Europe 2025. Cette abondance ne crée pas seulement des problèmes de performances, mais aussi du « bruit qui peut gêner l’identification d’incidents ou ses causes profondes ». « Nous avons rencontré le même problème avec la librairie Java ».
D’autant que ces données supplémentaires concernent majoritairement ce qu’il se produit en entrée et en sortie d’une application, selon Adriel Perkins, principal DevOps Engineer chez Liatrio, un cabinet de consultance américain spécialisé dans l’approche DevOps.
Les développeurs qui n’ont pas fait l’effort d’instrumenter manuellement leur code avec OpenTelemetry doivent alors appliquer des filtres. « Cela prend du temps », ajoute Adriel Perkins.
Une convention sémantique et des collecteurs sujets aux variations
L’instrumentation manuelle peut résoudre ce problème et permet d’affiner les données collectées. Là encore, il y a des contre-exemples. Outre la mise en place de collecteurs, elle est fonction d’une convention sémantique dont les attributs évoluent avec le projet OpenTelemetry. Les changements peuvent affecter la récupération de télémétrie, d’après les témoignages d’Alexandre Magno Prado Machado, ingénieur SRE chez la fintech Pismo et James Moessis, ingénieur logiciel senior chez Atlassian. « Les contributeurs du groupe de travail sur la convention sémantique doivent s’entendre, ce qui peut prendre du temps pour obtenir quelque chose de stable », estime James Moessis.
Il en va de même pour les collecteurs qui évoluent très rapidement. « Les collecteurs sont sujets à beaucoup d’instabilité », remarque Elena Kovalenko. « Nous gérons plus de 100 000 collecteurs […] et ces changements peuvent casser des choses, surtout quand les collecteurs n’existent que dans des versions expérimentales ou en bêta », témoigne James Moessis.
Des défauts de jeunesse qui n’effraient pas les grands comptes
Autant de problèmes qui sont en grande partie liés aux forces d’OpenTelemetry : sa modularité et ses nombreux contributeurs.
Pour David Szegedi, chief architect au sein de la direction technique de Red Hat, il s’agit principalement de problèmes de jeunesse. OpenTelemetry est né de la fusion des projets OpenTracing et OpenCensus en 2019. Ce problème de jeunesse serait particulièrement sur les fonctions de filtrage qui ne sont pas aussi avancées que celles de Prometheus.
De fait, Prometheus est d’abord une base de données time series et un système de monitoring plutôt qu’un moyen de collecter des données. D’ailleurs, un groupe de travail au sein d’OpenTelemetry tente de simplifier l’intégration avec Prometheus depuis 2021. Un autre groupe cherche à créer un langage de filtrage de type SQL pour Otel.
L’automatisation de la configuration des collecteurs, l’intégration d’eBPF, la récupération de la télémétrie depuis les chaînes CI/CD, la prise en charge de la notion de FinOps sont également des éléments importants dans les discussions des contributeurs.
« Les clients plus avancés sur Prometheus y vont plus doucement, ou adoptent OpenTelemetry pour envoyer des données vers d’autres plateformes ».
David SzegediChief architect au sein de la direction technique de Red Hat
Autant d’éléments influencés par les grands comptes, selon Red Hat et Splunk.
« De plus en plus de clients qui démarrent sur OpenShift utilisent OpenTelemetry puisque cela leur semble plus aisé pour faire de l’intégration dans les solutions d’observabilité qu’ils ont déjà », note David Szegedi. « Les clients plus avancés sur Prometheus y vont plus doucement, ou adoptent OpenTelemetry pour envoyer des données vers d’autres plateformes ».
« Par exemple, un de nos grands clients français, un industriel dans les produits dérivés de l’automobile, a fait le choix de s’appuyer exclusivement sur OpenTelemetry pour la collecte de télémétrie », relate-t-il. « C’est un signal fort. C’est un client de Splunk depuis des années. Il nous a challengés aussi en nous disant : “Je vous aime beaucoup, mais si vous n’êtes pas bon sur la partie OpenTelemetry, vous sortez”. Nous avons répondu à cette exigence. Ce ne sont plus les startups et les entreprises cloud natives qui le réclament ».
