blog.6admin.io
guest@6admin.io:~$
observability, opentelemetry, tracing, devops, logs

Trace-first : quand l'observabilité veut nous faire revenir aux logs

Les traces peuvent-elles remplacer une grande partie des logs applicatifs ? Et si oui, pourquoi OpenTelemetry propose-t-il désormais de déprécier son API d’événements de span au profit de l’API Logs ?

Entre simplification des API, corrélation des signaux et choix d’architecture, la question mérite mieux qu’une guerre de chapelles. Derrière ce changement se trouve un enjeu très concret : comment comprendre rapidement pourquoi une opération a échoué, sans devoir reconstruire soi-même le contexte à partir de données dispersées ?

Des métriques aux traces : une évolution logique

Les métriques sont indispensables pour suivre l’état d’un système : charge CPU, mémoire, latence, taux d’erreur ou saturation, elles permettent de détecter une dégradation et d’en suivre l’évolution. Mais elles ne suffisent pas toujours à expliquer ce qui s’est passé lors d’une opération particulière.

Les logs apportent davantage de détails, ils décrivent des événements, des erreurs et des situations rencontrées par l’application. Le problème est que ces informations peuvent être hétérogènes, dispersées entre plusieurs services et difficiles à rapprocher lorsqu’elles ne partagent pas un contexte commun.

Le tracing distribué propose une autre manière d’organiser ces informations : une trace représente le parcours d’une opération à travers un ou plusieurs composants. Elle regroupe des spans, qui décrivent des étapes de ce parcours, leur durée, leur statut et leurs attributs. Des événements horodatés peuvent également être associés à un span.

Le mot mérite qu’on s’y arrête, car aucune traduction française ne le rend à elle seule et chacun de ses sens éclaire un peu ce qu’il désigne. Un span, c’est d’abord une travée, celle d’un pont entre deux piles ou d’une charpente entre deux appuis, et c’est aussi une portée, la distance qu’un élément franchit sans soutien, ou encore une envergure, comme celle d’une aile ou d’une voile d’un bout à l’autre. C’est également une durée, un laps de temps borné par un début et une fin, comme dans “time span” ou “life span”, et en tant que verbe, “to span” signifie couvrir, s’étendre sur, traverser, enjamber ou recouvrir. Tous ces sens se retrouvent dans le span d’une trace, qui est à la fois un intervalle de temps borné, une étape qui enjambe une partie du parcours, et une travée parmi d’autres dans le pont que forme la trace complète, ses spans enfants venant s’y imbriquer comme autant de portées plus courtes. Faute d’équivalent qui rende tout cela, je garderai donc le terme anglais, que la documentation française d’OpenTelemetry conserve d’ailleurs elle aussi.

Cette organisation permet de replacer une erreur dans le déroulement d’une opération plutôt que de la considérer comme un simple message isolé.

Dans son article d’août 2023, “Tracing avec OpenTelemetry : pourquoi c’est le futur (et pourquoi ça remplacera les logs)” , Michaël Corbin présente cette approche et ses possibilités. C’est cet article qui m’a fait découvrir OpenTelemetry et m’a amené à réfléchir à la place que les traces pourraient prendre dans une architecture d’observabilité.

L’idée n’est pas simplement d’ajouter un signal supplémentaire à une stack existante : elle consiste à se demander si le contexte fourni par une trace peut rendre une partie des logs traditionnels moins nécessaire.

De la supervision Linux à l’observabilité moderne

Mon intérêt pour la supervision s’est concrétisé en 2012, lorsque j’ai rejoint la cellule Linux d’un datacenter universitaire, où j’étais notamment chargé de la supervision et de l’automatisation.

À cette époque, la supervision reposait principalement sur Zabbix, tandis que la journalisation système, avec syslog et rsyslog, constituait un autre volet de l’exploitation. Ces mécanismes répondaient à des besoins complémentaires : surveiller l’état des machines, détecter les anomalies et examiner les événements consignés pour approfondir les diagnostics.

Il faut replacer ces outils dans leur contexte historique. Je ne parle pas ici de tracing distribué moderne, avec propagation de contextes de trace et de span entre services : il s’agissait d’abord de supervision système, de collecte de journaux et d’automatisation opérationnelle, et des premières tentatives pour corréler tout cela.

C’est d’ailleurs à cette période que l’on a commencé à parler sérieusement d’ELK à la fac : Elasticsearch, Logstash et Kibana promettant enfin de centraliser des journaux jusque-là éparpillés sur des centaines de serveurs et de les interroger autrement qu’à coups de grep. C’est là que j’ai fait mes premiers essais (ELK <3). Je ne l’ai pourtant vraiment exploité que plus tard, d’abord dans l’infogérance de plateformes web à fort trafic pour des médias, puis en environnement bancaire et de marché, où la volumétrie, la rétention et la capacité à retrouver rapidement le fil d’un incident à travers des systèmes hétérogènes n’avaient plus rien d’un confort. Avec le recul, c’est sans doute là que j’ai le plus ressenti la limite de l’exercice, car centraliser les logs ne suffit pas à les relier, et l’on finissait souvent par reconstruire à la main, à partir d’horodatages et d’identifiants plus ou moins bien propagés, le parcours d’une requête que personne n’avait pensé à décrire.

Mais la question de fond était déjà là : comment passer du constat d’un incident à la compréhension de sa cause, sans multiplier les opérations manuelles ?

Les outils et les architectures ont évolué depuis. Nagios et Centreon appartenaient à une autre période de mon parcours, antérieure à la fusion universitaire. J’ai ensuite croisé OMD, Shinken et Icinga au fil de mes pérégrinations professionnelles, pour revenir maintes fois sur Zabbix et finalement adopter Prometheus, Loki et Grafana dans mon environnement.

En 2023, la lecture de l’article de Michaël Corbin m’a donné un nouveau point de comparaison pour aborder cette problématique. J’ai ensuite été amené à adopter OpenTelemetry dans le contexte de l’évolution de Traefik.

Avec Traefik v3, dont la première version stable est sortie le 30 avril 2024, le tracing a évolué vers une approche standardisée autour d’OpenTelemetry et d’OTLP, au lieu de s’appuyer sur les intégrations directes avec des fournisseurs spécifiques comme Jaeger. Cette évolution a constitué un déclencheur concret pour passer à OpenTelemetry dans cet environnement.

Vers 2025, mon environnement d’observabilité a évolué vers une stack associant VictoriaMetrics, VictoriaLogs, Fluent Bit, OpenTelemetry et Grafana.

Ce parcours ne signifie pas que toutes ces briques répondent au même besoin, ni qu’une technologie remplace mécaniquement la précédente : il illustre plutôt une continuité, celle de rendre les systèmes observables et de faciliter le diagnostic, tout en faisant évoluer les moyens techniques employés pour y parvenir.

Une trace peut-elle remplacer les logs applicatifs ?

Dans son article de janvier 2026, “Un exemple d’observability trace-first” , Michaël Corbin pousse le raisonnement plus loin en faisant des traces le point d’entrée privilégié de l’investigation, puisqu’une application correctement instrumentée permet de retrouver dans ses spans une bonne partie de ce que l’on aurait autrefois consigné dans des logs, qu’il s’agisse du contexte d’exécution, des attributs techniques ou métier, des erreurs ou des événements horodatés.

Imaginons une API qui refuse une opération parce que l’utilisateur ne dispose pas des droits nécessaires : un log classique contiendrait sans doute quelque chose comme Authorization denied for user 123 on resource 456, ce qui est utile mais laisse bien des questions en suspens. Quelle opération l’utilisateur tentait-il d’effectuer, quel service a pris la décision, combien de temps la requête a-t-elle duré, d’autres appels ont-ils échoué dans le même parcours, et l’échec vient-il d’une dépendance défaillante ou d’une règle métier ?

Avec une instrumentation adaptée, la trace apporte une partie de ces réponses dans un même contexte, puisqu’elle peut porter les attributs métier pertinents, le statut de l’opération, les étapes traversées et les événements survenus pendant son exécution, ce qui évite de produire des logs qui ne feraient que répéter ce que les spans contiennent déjà.

Encore faut-il ne pas tomber dans l’excès inverse, car trace-first ne signifie pas tout mettre dans les traces ! Une instrumentation trop bavarde fait grossir le volume de données, le coût du stockage et la complexité des requêtes. Les attributs à forte cardinalité alourdissent certaines analyses, et les données métier comme les identifiants personnels imposent leurs propres contraintes de confidentialité et de rétention.

Le véritable enjeu consiste donc à décider quelles informations doivent être rattachées au contexte d’une opération, lesquelles relèvent d’événements indépendants et lesquelles gagneraient à être agrégées sous forme de métriques.

Mars 2026, OpenTelemetry veut unifier la représentation des événements

Le 17 mars 2026, OpenTelemetry a publié un billet annonçant son intention de déprécier son API d’événements de span, “Deprecating Span Events API” , afin de privilégier l’API Logs pour représenter les événements plutôt que de conserver deux mécanismes distincts capables d’émettre des informations similaires.

À première vue, le changement paraît raisonnable, puisque les événements de span comme les enregistrements de logs portent des données structurées, des horodatages et des attributs, et que maintenir deux façons de représenter des informations comparables finit toujours par produire des écarts d’instrumentation, de conventions et de traitement selon les SDK ou les backends. L’objectif est donc de réduire cette duplication en standardisant les événements sous forme de logs, tout en conservant la possibilité de les corréler avec les traces.

Il faut néanmoins distinguer le modèle de données, c’est-à-dire la manière dont un événement est représenté et produit par l’application, de l’expérience d’investigation, autrement dit la manière dont un opérateur retrouvera cet événement dans le contexte d’une trace. Un modèle plus uniforme peut simplifier les API sans rendre l’investigation plus simple pour autant.

C’est précisément là que se situe ma réserve.

Le problème n’est pas le format, mais le parcours d’investigation

Prenons un événement authorization.denied associé à une requête HTTP : tant qu’il reste attaché à un span, son contexte est immédiat et la trace suffit à retrouver l’étape concernée ainsi que le reste du parcours.

S’il devient un enregistrement de log exporté séparément, plusieurs questions se posent alors. Le log conserve-t-il le contexte de trace et de span, le backend permet-il de le retrouver automatiquement depuis la trace, l’événement apparaît-il dans la chronologie de l’opération, peut-on le filtrer par attributs sans perdre le contexte de l’appel, et la corrélation tient-elle encore lorsque les données sont réparties entre plusieurs systèmes de stockage ?

Ces questions ne remettent pas en cause l’intérêt de l’API Logs : elles rappellent simplement que la qualité d’une architecture d’observabilité ne dépend pas que de la manière dont les données sont émises. Si l’on doit quitter la trace, ouvrir un autre outil, reconstruire ses filtres, retrouver les identifiants puis rapprocher les événements à la main, une bonne partie de la simplicité recherchée aura disparu en route, et la complexité, plutôt que de disparaître, se sera déplacée de l’instrumentation vers le pipeline de collecte, le stockage, les requêtes et l’interface d’investigation.

La dépréciation de l’API Span Events ne signifie pas pour autant que les événements cesseront d’être visibles dans une trace. Tout dépendra de la façon dont les SDK, les pipelines et les backends prendront en charge leur corrélation et leur présentation, et c’est donc sur le résultat opérationnel qu’il faudra juger la migration plutôt que sur la seule cohérence des API.

Unification des signaux ou retour à des silos ?

OpenTelemetry ne cherche pas à abandonner les traces au profit des logs : la proposition porte sur la manière de produire les événements et n’impose nullement de renoncer à leur association avec une opération distribuée. La distinction a son importance, car traces et logs peuvent être stockés, échantillonnés et conservés selon des politiques différentes, si bien qu’une trace échantillonnée peut laisser derrière elle des logs orphelins, tandis qu’une politique de collecte ou de rétention mal alignée peut faire disparaître les événements nécessaires à la compréhension d’une trace toujours présente. Dans les deux cas, des identifiants de corrélation ne garantissent en rien que les données utiles soient effectivement disponibles.

Une architecture cohérente devrait donc définir explicitement les règles d’échantillonnage des traces, les conditions de conservation des événements et des logs, les durées de rétention de chaque signal, les attributs et identifiants nécessaires à leur corrélation, et le comportement attendu lorsque l’un d’eux vient à manquer.

Il faut aussi distinguer la standardisation de l’instrumentation de l’unification du stockage, puisque des traces et des logs peuvent respecter les conventions OpenTelemetry tout en vivant dans des systèmes distincts, ce qui peut être un choix parfaitement pertinent, à condition de ne pas supposer qu’une API commune suffise à garantir une expérience d’investigation unifiée.

Ce que je voudrais préserver

À mes yeux, une architecture trace-first doit préserver quelques propriétés.

1. Une unité d’investigation claire

La trace doit permettre de comprendre le déroulement d’une opération, ses étapes, ses erreurs et ses dépendances, sans que l’opérateur ait à reconstruire ce contexte à partir de messages indépendants.

2. Une corrélation native

Les identifiants de trace et de span doivent être propagés et conservés correctement, et les événements exportés séparément doivent rester accessibles depuis le contexte de l’opération.

3. Des politiques d’échantillonnage cohérentes

Réduire le volume des traces ne devrait pas créer d’angles morts imprévus, ce qui suppose de concevoir la conservation des événements en fonction des besoins de diagnostic.

4. Une instrumentation raisonnable

Il ne s’agit pas de transformer chaque variable, chaque branche de code et chaque message de log en attribut de span, mais de retenir les informations qui apportent une vraie valeur à l’investigation, en tenant compte de leur cardinalité, de leur sensibilité et de leur coût.

5. Une certaine indépendance vis-à-vis du backend

L’intérêt d’un standard tient aussi au fait de ne pas lier toute l’instrumentation à un fournisseur. Il faut encore évaluer cette indépendance en pratique, au regard des conventions prises en charge, des fonctionnalités disponibles, de la qualité des requêtes et de la navigation entre signaux.

La standardisation ne devrait pas obliger à sacrifier ce qui rendait l’architecture utile.

Et si le véritable sujet était l’architecture d’observabilité ?

Métriques, logs et traces jouent des rôles complémentaires : les premières détectent une dégradation à l’échelle d’un service ou d’une infrastructure, les logs restent utiles pour les événements sans lien avec une requête, qu’il s’agisse d’un démarrage de processus, d’une tâche planifiée ou d’une erreur survenue avant même qu’une trace ait pu être créée. Les traces permettent de suivre une opération en replaçant chaque événement dans son déroulement.

Une approche trace-first fait de la trace le point de départ de l’investigation sans prétendre que tous les signaux doivent se fondre dans un seul format. Dans une architecture bien pensée, une alerte issue des métriques mène aux traces concernées, lesquelles donnent accès aux logs associés lorsqu’on en a besoin, chaque signal garde son utilité mais leur rapprochement devient une fonctionnalité de l’architecture plutôt qu’un travail manuel de l’opérateur.

Les choix de stockage et de visualisation restent déterminants : Grafana Tempo, les architectures bâties sur ClickHouse ou les plateformes qui proposent une exploration intégrée de plusieurs signaux répondent à des contraintes différentes, et aucune ne garantit une bonne expérience au seul motif qu’elle accepte plusieurs types de données.

Avant de remplacer une stack ou de toucher aux conventions d’instrumentation, je chercherais donc à mesurer quelques éléments très concrets, comme le coût d’ingestion et de rétention, la qualité et la rapidité des requêtes, la facilité à passer d’une alerte à une trace puis aux événements associés, la fidélité du contexte conservé lors des exports, et la capacité à diagnostiquer un incident lorsqu’une partie des données a été échantillonnée ou manque à l’appel.

Le bon choix n’est pas forcément celui qui réduit le plus le nombre de composants : c’est celui qui donne accès aux informations utiles avec le moins de friction, sans ouvrir de nouveaux angles morts.

Conclusion : ne confondons pas standardisation et simplification

La volonté d’OpenTelemetry de réduire la duplication entre l’API d’événements de span et l’API Logs se comprend : une instrumentation plus cohérente peut faciliter l’adoption du standard et limiter les écarts entre implémentations. Pour autant, la simplicité d’une API et celle d’une architecture d’observabilité ne sont pas la même chose.

Le trace-first est avant tout un choix opérationnel, celui de prendre le contexte d’une opération comme point de départ pour comprendre ce qui s’est passé, les événements et les logs gardant toute leur utilité tant qu’ils enrichissent ce contexte sans obliger l’opérateur à le reconstruire.

Si l’évolution d’OpenTelemetry préserve cette expérience, elle aura été une amélioration. Si elle oblige à reconstituer ailleurs ce qui était jusque-là accessible directement dans la trace, elle n’aura fait que déplacer la complexité.

Au fond, le critère qui compte reste simple : lorsqu’une opération échoue, peut-on comprendre pourquoi en partant de sa trace, sans devoir devenir l’intégrateur de sa propre chaîne d’observabilité ?

C’est à cette question que l’architecture, les pipelines et les outils devront répondre.

Références