Démystifier le traçage distribué : améliorer la performance des applications

Introduction au traçage distribué

À l’ère technologique actuelle, il devient de plus en plus difficile pour les équipes DevOps de suivre leur pile applicative, car la nature des opérations de service accentue leur distribution. Cela complique davantage la tâche de déterminer la pleine mesure d’un problème de performance et son impact sur toute l’infrastructure. Par exemple, des indicateurs de performance comme le temps de réponse et les appels externes indiquent l’existence probable d’un problème dans le système, mais sans clarifier son origine exacte.

Les applications modernes utilisant un modèle de microservices largement distribués pour gérer leurs opérations, l’équipe DevOps éprouve souvent des difficultés à tenter de suivre, d’isoler et de corriger les problèmes de performance avant que l’utilisateur ne soit affecté. Le mieux consiste alors à identifier le sous-système dans lequel réside le problème, puis à chercher en profondeur. Toutefois, cette méthode oblige les développeurs à y consacrer beaucoup de temps et d’énergie, au détriment des tâches de production et de déploiement.

C’est là qu’intervient le traçage distribué. L’instrumentation permet à l’équipe DevOps et la DSI de suivre une requête de bout en bout et de corréler les données distribuées pour identifier le point exact où l’application connaît un problème d’exécution.

Qu’est-ce que le traçage distribué ?

Le traçage distribué consiste en une technique d’analyse pour comprendre le parcours que suit une requête dans la pile applicative. En utilisant des balises d’identification spécifiques, le traçage distribué enregistre les détails d’exécution de chaque opération que subit la requête. Les développeurs peuvent ainsi distinguer les opérations d’un système distribué et le temps que prend chaque service pour s’exécuter. Le traçage distribué cartographie aussi la relation entre différentes opérations de la pile applicative pour représenter visuellement tout le parcours et faciliter le débogage.

Pourquoi a-t-on besoin du traçage distribué ?

Dans une architecture monolithique, un aperçu global suffit souvent pour assurer l’observabilité des applications, car tout le système fonctionne de façon unifiée avec des opérations locales, exécutant un nombre identifiable de fonctions à un moment donné. Dans ce cas, le traçage classique suffit, car la requête passe par un seul système qui réunit tous les éléments.

Toutefois, les applications utilisant une architecture de microservices présentent un vaste réseau de services interconnectés pour réaliser différentes opérations. Les DSI préfèrent en général cette solution, car elles recherchent un environnement applicatif flexible et facilement adaptable. De petites équipes de développement pouvant gérer chaque service, la solution des microservices leur offre la flexibilité de déployer de nouvelles piles technologiques pour différentes opérations et d’utiliser des API bien définies pour assurer une communication fluide entre elles. De plus, les équipes peuvent aussi tester et déployer des mises à jour sans interférer avec l’exécution d’autres services.

Un environnement de microservices assure l’indépendance des éléments, évitant que le système ne défaille totalement. On peut alors limiter le problème à une seule opération pour l’isoler facilement et le corriger en atténuant l’impact. Toutefois, cela amène à se demander comment isoler un tel problème.

Malgré les nombreux avantages qu’offre une architecture de microservices, ce degré de personnalisation et de flexibilité présente aussi un inconvénient. En effet : Par exemple, une requête passe par plusieurs services reliés entre différents environnements applicatifs, chaque service pouvant gérer des tâches pour diverses opérations. Donc, lorsqu’une transaction a lieu, une requête peut appeler plusieurs services l’un après l’autre. Dans un tel cas, si l’un des services s’avère lent, cela affecte les opérations suivantes et les ralentit aussi. Cette chaîne d’événements augmente conjointement le temps de réponse global de la transaction ou de l’événement précis, les administrateurs ayant plus de mal à localiser l’origine du problème.

Le traçage distribué permet à l’équipe DevOps d’afficher l’interaction et la relation entre les services pour des détails précis sur le problème de performance rencontré dans la pile applicative. Une fois qu’elles ont identifié le service précis dont le traitement prend trop de temps, l’équipe IT concernée peut être avertie. Elle peut alors identifier facilement les erreurs, les corriger et optimiser l’infrastructure informatique pour une meilleure collaboration entre les microservices.

Cela n’implique pas pour autant que le traçage distribué serait inutile à une architecture monolithique. Une telle architecture peut bénéficier du traçage distribué pour améliorer et accélérer le débogage.

Terminologie du traçage distribué :

• Span : Un span représente la durée que prend un seul service pour effectuer son opération prévue, comme une réponse de serveur, une requête HTTP, des appels d’API ou des requêtes de base de données. Une requête passant par chaque service, un span est alors généré, le premier portant le nom de span parent et le ou les autres d’enfants. En d’autres termes, chaque span, hormis la première opération, possède un parent.
• Trace : Une trace représente toute l’action qu’effectue une requête de bout en bout. Il s’agit du temps total que prennent tous les services par lesquels passe une requête. En substance, une trace est l’ensemble d’un ou de plusieurs spans. Une trace peut commencer lorsqu’un utilisateur interagit avec l’application et s’achever au point où la requête est traitée.
• ID de trace : Chaque requête se voit affecter un identifiant unique, appelé ID de trace. Un ID de trace accompagne une requête afin de permettre de cartographier tout son flux pour comprendre l’interaction entre les services.
• ID de span : Chaque opération de span se voit affecter un ID.
• Span parent et enfant : On différencie en général les spans pour comprendre les dépendances entre les services au fil du flux d’une requête. Un span parent représente toujours l’opération de service précédente alors que l’enfant représente le service qui suit. La durée de chaque span parent dépend de son enfant. Lorsque l’exécution d’un span enfant donné dure trop longtemps, tous les spans précédents se prolongent simultanément. Cette méthode aide à déterminer la zone exacte où survient un problème.

Comment fonctionne le traçage distribué ?

Pour comprendre comment fonctionne le traçage distribué, considérons un scénario où un utilisateur tente de se connecter à son compte dans une application Web :

Lorsque l’utilisateur tente de se connecter à son compte, une requête HTTP est générée par le frontal de l’application Web, puis elle passe par une série de services pour récupérer des données du serveur de base de données. Supposons que la requête HTTP doit subir une chaîne d’actions pour exécuter complètement tout le processus. Dans ce cas, la requête HTTP a le flux suivant : frontal → service 1 → service 2 → service 3 → serveur de base de données et retour.

Considérons un cas où il s’avère qu’un utilisateur de l’application Web doit attendre longtemps juste pour ajouter un produit au panier. Un tel événement frustre certainement l’utilisateur qui risque d’abandonner l’achat, d’où un impact opérationnel et une perte financière. Lors du contrôle, les développeurs ne peuvent connaître que le temps de réponse global de la transaction, sans idée de l’efficacité opérationnelle des services concernés.

Le traçage distribué permet alors de collecter des données à chaque étape par laquelle passe la requête jusqu’à ce qu’elle atteigne son point final. En analysant les détails de traçage distribué, l’équipe DevOps peut repérer visuellement le service précis ayant contribué le plus au ralentissement et provoqué une forte hausse du temps de réponse global.

Dans ce scénario, le traçage distribué opère en affectant un ID de trace à la requête qui la suit à travers les services et le serveur de base de données. Le span de chaque service se calcule selon le temps qu’il prend pour recevoir une requête et l’exécuter entièrement.

Le span D représente donc le stade où la requête HTTP est reçue par le serveur du service 3. Le span C commence lorsqu’une requête est envoyée au serveur de base de données et s’achève à la réception d’une réponse. De même, le span B s’achève lorsque la réponse HTTP est reçue par le service 2 et le span A à sa réception par le service 1. Dans ce scénario, A est le span parent de l’enfant B. De même, B est le span parent de C et ainsi de suite.

Lorsqu’une hausse soudaine du temps de réponse d’une transaction est détectée, les administrateurs peuvent suivre les traces de chaque span. En les examinant tous, ils trouvent que les spans A à C présentent un temps de réponse élevé alors que D est exempt d’anomalies. C étant le span enfant inférieur, le résolution du problème à ce niveau le réglerait en général, car les parents ne sont que des dépendances. Plusieurs raisons peuvent expliquer le problème : pic de trafic, pic d’utilisation, bogues, erreurs, chevauchement de tâches, etc.

Comment effectuer le traçage distribué avec Applications Manager :

Maintenant, si toute l’exécution d’une action dure trop longtemps, un système réalisant un traçage distribué collecte normalement des métriques de performance importants de chaque service. Un outil d’analyse de la performance des applications comme Applications Manager permet d’effectuer le traçage distribué pour scinder visuellement chaque span et localiser le ralentissement.

Quelques étapes simples suffisent à télécharger Applications Manager et le configurer dans le système. Dans le volet du tableau de bord, créez un moniteur pour les applications Web exécutées sous Java, node js, .Net, Ruby on Rails, Python, PHP ou .Net Core. Une fois votre propre moniteur d’applications configuré, le traçage distribué s’effectue facilement.

Applications Manager offre un volet APM dédié qui centralise tous les moniteurs d’applications. En parcourant chaque moniteur d’applications, voici comment effectuer le traçage distribué avec Applications Manager :

1. Ouvrez le volet Aperçu du moniteur d’applications. Le tableau de bord donne un aperçu global de l’exécution des transactions.
2. Il contient un graphique à barres qui affiche les cinq traces les plus lentes dans l’ordre.

3. Pour effectuer le traçage distribué, sélectionnez la transaction lente à s’exécuter. Vous obtenez une toute nouvelle forme d’analyse de trace avec une répartition détaillée des étapes que suit l’appel ou la requête.
4. Chaque span est coloré selon le type d’élément pour faciliter l’identification et la résolution des problèmes.
5. L’option de traçage distribué offre une vue en cascade qui affiche toutes les traces dans l’ordre. Les développeurs et les administrateurs peuvent suivre chaque span à partir du haut pour localiser le ralentissement.
6. Le temps de réponse s’affiche pour chaque trace.

7. L’outil de traçage distribué d’Applications Manager permet aussi d’agrandir et de réduire les listes déroulantes pour mieux isoler la zone de trace entraînant le problème de performance.
8. Pour une résolution rapide des problèmes, Applications Manager offre aussi un bouton bascule. Une fois la bascule activée, l’outil indique immédiatement les traces qu’il suspecte de provoquer le problème de performance. On peut ainsi accéder instantanément à la section où réside la trace lente.

Lien entre l’analyse de la performance des applications et le traçage distribué :

L’adoption d’un outil d’analyse de la performance des applications intégrant le traçage distribué offre les avantages suivants :

Résolution rapide des problèmes : les équipes peuvent examiner toutes les étapes de la trace de transaction et mieux identifier les éléments fautifs. Les développeurs n’ont plus à balayer chaque journal et consacrer des heures au débogage. L’outil signale instantanément l’origine du problème pour qu’ils s’y attachent directement. Cela réduit nettement le MTTR, d’où moins d’interruptions. Par exemple, si le problème concerne l’ajout au panier, le traçage distribué permet de l’isoler à ce niveau.

Gain de productivité par la collaboration des équipes : différentes équipes gérant en général les microservices, le traçage distribué identifie le module de service précis qu’il faut examiner. Ainsi, lorsqu’une équipe rencontre un problème dans tout le flux de requête, elle identifie et informe celle concernée en charge de la cause du ralentissement. Elle peut alors corriger le problème.

Flexibilité : l’utilisation du traçage distribué dans la stratégie de gestion des applications facilite l’adaptation de l’organisation en cas de besoin. Cela lui permet d’élargir son environnement de microservices avec de nouvelles opérations sans hésiter, car elle s’appuie sur le traçage distribué.

Meilleure expérience utilisateur : lorsqu’un utilisateur navigue difficilement dans une application Web, le problème réside souvent dans une seule opération de service. Tout le processus ralentit alors, nuisant au niveau de satisfaction (note APDEX) des utilisateurs de l’application. Le traçage distribué permet de cerner le problème sans qu’il n’affecte l’expérience utilisateur.

Devancer la concurrence avec le traçage distribué :

Un nombre croissant d’applications Web adoptant une architecture de microservices, il devient essentiel d’obtenir aussi un suivi distribué. Le traçage distribué permet aux équipes IT et DevOps d’identifier, d’analyser et de résoudre les problèmes pour offrir un environnement de services fiable dans la pile applicative. Il assure une prise de décision éclairée pour optimiser la performance et régler rapidement les problèmes.

En bref, le traçage distribué est l’un des éléments clés que les outils d’instrumentation doivent offrir pour obtenir un aperçu complet des interdépendances dans une pile applicative. Applications Manager offre un tel outil. Il intègre le traçage distribué à l’analyse de la performance applicative et permet aux entreprises de veiller à ce que les applications métier répondent aux attentes de l’utilisateur.

Souhaitez-vous analyser vos applications et l’infrastructure informatique ?

Démarrez dès maintenant en téléchargeant une version d’évaluation gratuite de 30 jours pour découvrir toutes les fonctionnalités de notre solution d’analyse ou prévoyez une démo personnalisée pour une visite guidée.