Points clés
- Le traçage de bout en bout complet est rarement atteignable dans les systèmes distribués : diversité des langages, API externes, composants legacy et services éphémères créent des angles morts qu’on ne peut pas toujours combler.
- Les données de traçage manquantes engendrent d’autres problèmes : une visibilité partielle allonge le délai de résolution et fait perdre confiance dans les données de surveillance.
- Une visibilité partielle reste utile : en standardisant ce qui peut être mesuré et en le corrélant avec les journaux, les équipes comblent les manques par déduction.
- Les dépendances externes demandent une autre approche : pour les composants qui échappent à votre contrôle, suivez la trace aussi loin que possible, puis servez-vous des données corrélées pour déduire ce qui se passe.
Le traçage de bout en bout prend de plus en plus d’importance pour les équipes techniques et DevOps chargées de maintenir aussi bien les outils internes que les applications destinées au public. Mais il s’avère difficile à mettre en place dans les systèmes reposant sur des microservices distribués.
Ce guide explique ce qui peut arriver lorsque le traçage de bout en bout se rompt (ou reste impossible) dans les systèmes distribués, et comment y remédier.
Le traçage de bout en bout, qu’est-ce que c’est ?
Le traçage de bout en bout consiste à suivre intégralement une requête ou une transaction, de son émission à son aboutissement, à travers chaque composant d’un système. On l’utilise couramment pour déboguer le code applicatif, évaluer les performances, mais aussi repérer et éliminer les goulots d’étranglement.
Il est indispensable dans les systèmes distribués fondés sur des microservices, où il faut retracer le parcours complet d’une requête à travers plusieurs services modulaires, au lieu de simplement journaliser l’activité d’un codebase unique en cours d’exécution.
Prenons l’exemple d’un utilisateur qui valide son panier sur une application e-commerce bâtie sur des microservices : une requête part dès qu’il clique sur le bouton « Payer maintenant ». Cette requête arrive sur le serveur web, qui appelle un service de traitement des paiements, lequel, en cas de succès, appelle un service d’e-mail pour envoyer une confirmation de commande. Ce cheminement n’est pas forcément linéaire ni séquentiel : si une confirmation par SMS est également demandée, les services d’e-mail et de SMS peuvent être appelés en parallèle. Tracer une telle requête est plus complexe que dans un codebase monolithique unique, où tout se déroule au même endroit dans un ordre précis.
Pourquoi le traçage de bout en bout est si difficile dans les systèmes distribués
La complexité augmente encore dans les systèmes distribués composés d’éléments qui font appel à des langages, des bibliothèques et des plateformes différents. La nature éphémère des microservices qui montent en charge pose aussi problème : des nœuds sont créés puis détruits au rythme de la demande, certains ne vivant que le temps de traiter une seule requête. Lorsqu’un nœud disparaît, toutes les données de traçage qu’il contenait et qui n’avaient pas encore été persistées ailleurs disparaissent avec lui.
Parmi les autres obstacles fréquents au traçage de bout en bout :
- des systèmes qui ne prennent pas du tout en charge le traçage
- des services externes (API de communication, par exemple) sans aucune visibilité
- des composants legacy
- des formats de données incohérents
Les bases de données constituent un cas particulièrement épineux. Comme elles privilégient la performance et exécutent les requêtes en parallèle pour optimiser les lectures et les écritures, il devient difficile de déterminer quelle requête précise provoque un problème de performance en période de forte activité.
Problème : les systèmes distribués créent des angles morts dans l’observabilité
Un traçage de bout en bout complet suppose une visibilité sur chaque composant. Or, dans les systèmes distribués, ceux-ci forment souvent un ensemble hétérogène :
- du code sur mesure exécuté dans des conteneurs, dont l’activité peut être surveillée en détail
- des services cloud natifs comme les workers serverless, qui n’offrent parfois qu’une visibilité limitée
- des API tierces sans aucune observabilité
Ces composants peuvent tourner sur le même hôte ou être répartis, selon votre application. Même ceux qui partagent un environnement ne s’intègrent pas toujours directement : ils utilisent des langages et des systèmes d’exploitation différents et exigent des bibliothèques distinctes pour surveiller l’activité. Même les systèmes distribués conçus dès l’origine avec l’observabilité en tête finissent par présenter des angles morts à mesure qu’ils évoluent.
Solution : gagner en visibilité sans traçage complet
Il ne faut pas renoncer au traçage de bout en bout sous prétexte que vous ne pouvez pas tout tracer. Même si un traçage intégral n’est pas réaliste pour certains systèmes, vous pouvez veiller à collecter systématiquement toutes les données disponibles : faites avec ce que vous avez.
Cela suppose de mesurer de façon standardisée tout ce qui peut l’être, afin que ces mesures puissent être analysées et ne soient pas perdues. Là où vous gardez la main, renforcez l’intégration et l’instrumentation pour recueillir le maximum d’informations de diagnostic.
Problème : les conséquences des données de traçage manquantes
Des données incomplètes génèrent à leur tour leurs propres difficultés :
- identification malaisée des causes racines
- allongement du délai de résolution des incidents
- mauvaise interprétation du comportement du système
- perte de confiance dans les données de surveillance
Tout cela peut réduire à néant l’utilité des données de qualité que vous parvenez malgré tout à collecter.
Solution : travailler avec une visibilité partielle
Les manques peuvent être comblés par déduction. La surveillance des performances applicatives, par exemple, fournit des informations qui aident à deviner ce qui se passe à l’intérieur des composants « boîte noire ». De même, les requêtes de base de données peuvent être profilées séparément dans des environnements de test lorsqu’il n’est pas envisageable d’isoler l’activité en production.
Ces données peuvent ensuite être corrélées aux traces et aux journaux, ce qui vous permet de dégager des tendances et de combler les vides.
Problème : les frontières du système et les dépendances externes
Les dépendances externes, API, systèmes hébergés dans des environnements disparates, sans oublier les systèmes legacy qu’on ne peut pas doter de fonctions de traçage, rendent difficile le suivi d’une requête sur tout son cycle de vie.
Solution : l’importance du contexte dans le traçage distribué
Suivez la requête aussi loin que vos outils de traçage le permettent, puis comblez les vides en corrélant les statistiques comme décrit plus haut. Cela n’est possible qu’en maîtrisant parfaitement le système que vous surveillez, afin de vous concentrer sur les bonnes informations et de ne pas courir après des chimères en tentant de corriger des problèmes qui échappent à votre contrôle.
Renforcer l’observabilité pour tracer de bout en bout dans les systèmes distribués
Une application n’existe pas en vase clos : elle sert de véritables utilisateurs dans leurs tâches quotidiennes, et ces utilisateurs sont souvent bien placés pour repérer un comportement anormal. Pour faciliter le traçage de bout en bout, choisissez une solution de surveillance de l’infrastructure capable également d’ingérer et de traiter les données d’autres sources de surveillance, et d’envoyer des alertes dès qu’une anomalie est détectée. Associée à un helpdesk (service d’assistance), cette approche permet aux mécanismes automatisés comme aux utilisateurs finaux de signaler les problèmes applicatifs et de déclencher une investigation immédiate, ce qui augmente les chances de capturer les données pertinentes.
