Traces, métriques, logs : les trois signaux historiques d’OpenTelemetry répondent bien à « quoi » et « quand », beaucoup moins bien à « pourquoi ce pod consomme 4 cœurs pour traiter 200 requêtes par seconde ». Pour répondre à cette question-là, il fallait jusqu’ici un profiler dédié — souvent propriétaire, souvent payant, rarement corrélé au reste de ta télémétrie. Depuis le 26 mars 2026, OpenTelemetry a un quatrième signal officiel pour ça : les profiles, entrés en alpha publique.
Six mois plus tard, où en est vraiment ce signal, et est-ce raisonnable de commencer à s’y intéresser sérieusement ?
Ce que le profiling continu apporte concrètement
L’idée n’est pas nouvelle — Pyroscope, Parca ou le Continuous Profiler de Datadog font ça depuis des années. Ce qui l’est, c’est la standardisation : un format commun pour représenter des stacks d’appel échantillonnées en continu, avec une corrélation native aux traces via les mêmes trace_id et span_id. Concrètement, tu peux passer d’une trace lente dans Grafana Tempo ou Jaeger directement au profil CPU du service concerné, sans changer d’outil ni recorréler manuellement par timestamp.
Techniquement, la représentation est dédupliquée : chaque call-stack unique n’est stocké qu’une fois, référencé ensuite par index. Avec le support de dictionnaires de chaînes ajouté au format, l’annonce officielle parle d’une réduction de 40 % de la taille sur le réseau par rapport à une représentation naïve. Pour un signal dont le volume de données peut vite dépasser celui des traces classiques, ce n’est pas un détail cosmétique.
Les runtimes déjà supportés par l’agent eBPF
L’agent de profiling eBPF (celui qui échantillonne sans toucher au code de l’application) couvre aujourd’hui :
- Go, avec symbolisation automatique sur la cible ;
- Node.js (moteur V8), y compris sur architecture ARM64 ;
- Ruby, avec des améliorations récentes sur le unwinding et la symbolisation ;
- .NET 9 et 10 ;
- BEAM (Erlang/Elixir), en support initial, donc encore limité.
Si tu es sur du Python ou du Java pur JVM, la couverture native n’est pas encore là — à vérifier avant de bâtir un business case dessus.
Le vrai statut en septembre 2026 : encore alpha, et ça compte
L’annonce officielle est sans ambiguïté sur ce point : « with the Alpha status of the release, the signal should not be used for critical production workloads ». Ce n’est pas une formule de prudence juridique standard — les backends capables d’ingérer et d’exploiter ce format en production ne sont eux-mêmes pas encore matures partout. Le Collector OpenTelemetry sait déjà traiter et transformer des données de profiling, mais les receivers/exporters spécifiques évoluent encore vite dans opentelemetry-collector-contrib, au rythme de plusieurs changements par semaine.
Ma position là-dessus : c’est le bon moment pour tester sur un environnement de dev ou de préproduction, pas pour remplacer ton profiler de production actuel. Si tu utilises déjà Pyroscope ou un profiler propriétaire qui te satisfait, garde-le en place et suis l’évolution du signal en parallèle — la bascule aura plus de sens quand le format atteindra au minimum le statut bêta et que ton backend d’observabilité (Grafana, Elastic, ou autre) l’exposera nativement.
Comment ça s’articule avec ce qu’on a déjà couvert
Si tu as suivi la mise en production de l’instrumentation eBPF zero-code (OBI), la logique est la même côté infrastructure : pas de modification de code, un agent qui observe depuis l’extérieur. La différence est dans la donnée produite — OBI génère des traces et métriques à partir du trafic réseau observé, les profiles génèrent des échantillons de call-stacks CPU/mémoire. Les deux sont complémentaires, pas substituables l’un à l’autre.
Et si ta stack repose déjà sur l’interopérabilité OpenTelemetry/Prometheus mise en place récemment pour tes métriques, il vaut mieux garder le profiling dans un pipeline séparé pour l’instant : mélanger un signal alpha à une chaîne de métriques qui tourne en production, c’est prendre un risque de stabilité pour un gain qui reste expérimental.
FAQ
Faut-il réécrire son instrumentation existante pour profiter des profiles ?
Non. L’agent eBPF fonctionne sans instrumentation manuelle du code, à condition que ton runtime figure dans la liste supportée. C’est justement l’intérêt du zero-code appliqué au profiling.
Le format de profiling OpenTelemetry remplace-t-il pprof ?
Il s’en inspire largement et vise l’interopérabilité avec l’écosystème existant, mais l’objectif est de devenir un format d’échange standard indépendant du langage, pas juste un pprof rebaptisé.
Quand ce signal deviendra-t-il stable (GA) ?
Aucune date n’est publiée à ce stade. Le passage d’alpha à bêta, puis à stable, suivra le même processus de spécification que les trois autres signaux — ça s’est compté en années pour les traces et métriques, pas en mois.
Ce qu’il faut retenir
Le quatrième signal d’OpenTelemetry tient ses promesses sur le papier : corrélation native avec les traces, format compact, zero-code sur les runtimes courants côté backend. Mais il reste un projet alpha avec un avertissement explicite contre un usage en production critique. Le bon réflexe maintenant : l’évaluer en préproduction, suivre les releases hebdomadaires du Collector Contrib, et prévoir de revisiter la question dans quelques mois plutôt que de migrer ta stack de profiling dès aujourd’hui.
Laisser un commentaire