Maintenant que vous avez une idée de ce qu’est le traçage distribué, voyons à présent son fonctionnement. Contrairement aux applications monolithiques, les environnements de microservices s’exécutent sur des backends distribués, ce qui rend plus difficile le suivi du parcours complet des requêtes. Heureusement, le traçage distribué permet de suivre les actions des utilisateurs à chaque étape et de surveiller la façon dont cela affecte votre application, du frontend au backend. 

Le traçage distribué commence par instrumenter votre architecture de microservices. Il est possible d’utiliser des outils open source tels qu’OpenTelemetry pour démarrer le processus d’instrumentation et de collecte de données télémétriques. 

Ensuite, les développeurs doivent implémenter du code dans vos services afin de suivre les données de trace et d’associer des identificateurs uniques à chaque transaction. Le contexte codé est transmis d’un serveur à l’autre dans l’ensemble de l’environnement d’application. Les identificateurs associés aux transactions donnent une visibilité sur votre expérience client. 

Les outils de traçage distribué suivent chaque activité ou segment après avoir été déclenché par un événement lorsqu’il passe par un serveur. Au fur et à mesure qu’une étendue est collectée, elle passe à la suivante, et ainsi de suite. Ces étendues commencent généralement par l’étendue parent, puis passent aux étendues enfant. 

Votre outil mettra ces actions en ordre et collectera des indicateurs pertinents telles que les attributs personnalisés, les horodatages et les métadonnées. En général, un outil de traçage distribué permet de visualiser ces données sous la forme d’un graphique ou d’une vue en cascade. Grâce à ces graphiques, les ingénieurs peuvent déterminer quelles parties d’un système distribué présentent des goulets d’étranglement, des ralentissements ou des problèmes de performance. 

Enfin, il convient d’associer votre outil de traçage distribué à une plateforme d’observabilité afin de surveiller votre application de bout en bout. L’inclusion d’une plateforme comme Instana vous permet d’extraire et de traiter les données afin de prendre les bonnes mesures pour résoudre toute erreur d’application. 

La complexité des architectures modernes a rendu difficile pour les applications monolithiques traditionnelles de servir les outils qui les hébergent. Compte tenu de cette difficulté, le traçage distribué est devenu essentiel pour atteindre l’observabilité adéquate dans les environnements cloud natifs.

Voici les principaux avantages du traçage distribué :

• Résolution plus rapide des problèmes : Le temps moyen de résolution (MTTR) et le temps moyen de détection (MTTD) sont considérablement réduits. Les ingénieurs peuvent consulter les traces distribuées pour trouver l’origine des problèmes et localiser les erreurs d’application.

• Hausse du travail d’équipe : Dans l’environnement classique des microservices, les équipes spécialisées gèrent et développent différentes technologies. Cette situation peut être source de confusion parmi les équipes si elles ne savent pas où l’erreur s’est produite et qui est chargé de la résoudre. Un lien de trace permet aux équipes d’ingénierie de visualiser les données afin d’alerter le bon développeur pour qu’il corrige le problème. 

• Intégration et mise en œuvre flexibles : Les développeurs peuvent mettre en œuvre le traçage distribué dans presque n’importe quel environnement cloud natif. Les outils sont compatibles avec une large gamme de langages de programmation et d’applications. 

Chacun de ces avantages améliore les performances de l’application en vous donnant une idée de la manière dont chaque requête est traitée par votre serveur. Bien que le traçage distribué présente de nombreux avantages, il existe également certains inconvénients à prendre en compte. 

• Instrumentation manuelle : Certaines plateformes de traçage distribué obligent les développeurs à modifier leur code pour commencer à tracer les requêtes des utilisateurs. Le processus d’instrumentation manuelle exige de nombreuses heures de travail, rend votre application plus vulnérable aux bugs et peut manquer certaines traces.

• Absence d’analyse frontend : Lors de l’achat d’un outil de traçage distribué, il est important de s’assurer qu’il propose une couverture de bout en bout. À défaut, vous aurez seulement une visibilité sur le backend, et non sur le frontend et l’expérience des utilisateurs finaux. Cette contrainte peut rendre beaucoup plus difficile le débogage de votre application. 

• Échantillonnage : Certains outils de traçage distribué utilisent un échantillonnage arbitraire, qui choisit de manière aléatoire les traces à échantillonner et à analyser. Étant donné que les traces sont choisies au hasard et qu’il n’existe aucun moyen de savoir quelles traces présenteront des problèmes, les équipes risquent de passer à côté d’erreurs majeures. 

Bien que certaines difficultés puissent survenir lors de l’utilisation d’un système distribué, les avantages l’emportent presque toujours sur les inconvénients. Nous vous conseillons de combiner votre outil de traçage distribué avec Instana afin de pouvoir résoudre ces problèmes en temps réel. 

Pour comprendre la différence entre le traçage distribué et la journalisation, nous devons d’abord expliquer ce qu’est un journal. Un journal est l’horodatage d’un événement se produisant dans un système d’application. La journalisation surveille les événements importants identifiés dans les journaux afin de mettre en évidence les comportements imprévisibles au sein de votre application. Si une erreur se produit, cela déclenche une réponse automatique et alerte votre équipe DevOps. 

L’un des principaux inconvénients de la journalisation seule est qu’elle ne peut pas fournir un aperçu complet de la performance des applications sans traces. 

Le traçage distribué utilise des ID pour suivre les transactions sur votre système en tenant compte du contexte. Ce contexte vous permet de trouver l’endroit exact où une erreur s’est produite dans votre système. Une telle visibilité sur votre système basé sur les microservices réduit le temps de réponse en cas de détection d’une anomalie dans l’environnement transactionnel. De nombreuses équipes combinent donc le traçage distribué et la journalisation afin d’obtenir une vue d’ensemble de l’état de santé de leurs applications modernes.

Les outils de traçage distribué prennent généralement en charge l’instrumentation, la collecte de données et la visualisation des données dans des graphiques. La mise en place de solutions de traçage distribué s’effectue le plus souvent à l’aide d’outils open source. 

Voici une sélection des options open source les plus populaires du marché :

• OpenTelemetry : OpenTelemetry propose un ensemble de kits de développement logiciel (SDK), de logiciels de collecte de données, d’API non liées à un fournisseur et d’outils d’instrumentation. Il s’agit d’une combinaison d’OpenCensus et d’OpenTracing. Ce framework de surveillance des performances populaire pour les environnements cloud est l’un des outils de traçage distribué les plus appréciés. OTel n’inclut pas d’outils d’analyse ou de visualisation des données, mais il est possible d’envoyer des données télémétriques à des applications tierces pour effectuer cette recherche.

• OpenCensus : OpenCensus a été créé par Google sur la base de son système de traçage interne. Il a ensuite été rendu open source et est devenu disponible dans des bibliothèques multilangages. Il peut collecter et transférer des données vers des plateformes backend pour faciliter le débogage mais, malheureusement, il lui manque une API pour intégrer le logiciel dans le code. Cette limitation est l’une des principales raisons pour lesquelles OpenCensus et OpenTracing ont été combinés par la Cloud Native Computing Foundation (CNCF) pour créer OpenTelemetry. 

• OpenTracing : OpenTracing, API non liée à un fournisseur, permet aux développeurs d’instrumenter le code aux fins de traçage distribué. Ce projet open source est disponible dans neuf langages différents, dont Java, Python et Ruby. 

• Zipkin : Zipkin est un autre projet open source créé par Twitter. Ce système de traçage distribué aide les professionnels DevOps à collecter des données d’application importantes et à résoudre les problèmes de latence dans différentes architectures de services. Il est possible d’envoyer des données à Zipkin en utilisant Apache, Kafka ou HTTP.

• Jaeger : Jaeger est le projet open source le plus récent de cette liste. Il a été créé par Uber et s’intègre facilement à OpenTracing. Cet outil étant très élastique, cela en fait une excellente option pour le traçage des requêtes dans les environnements de microservices. Bien que Zipkin et Jaeger aident tous deux à la visualisation des statistiques, ils présentent des limites quant à l’échantillonnage des données.

Malgré la popularité d’OpenCensus et d’OpenTracing dans le passé, nous recommandons d’utiliser OpenTelemetry, Zipkin ou Jaeger. Nous vous conseillons de les utiliser en combinaison avec un outil APM ou d’observabilité tel qu’Instana afin de savoir exactement ce qui se passe dans votre application. 

Pour comprendre la façon dont les messages échangés entre votre application et ses composants interagissent, un système de traçage est indispensable. Avec Instana AutoTrace, vous ne manquerez jamais aucun contexte ni aucun appel grâce à ses capacités à capturer chaque requête et à corréler les traces provenant d’API open source. Instana vous facilite la tâche grâce à son diagramme dynamique.

Nous optimisons chaque trace entre votre architecture d’application, de service et de système pour vous offrir une couverture complète. Pour essayer Instana avec le traçage distribué, inscrivez-vous à notre essai gratuit de deux semaines et profitez de nos fonctionnalités.