Débuguer la trace la plus lente sur l'endpoint le plus lent d'un service web

Temps de lecture : 3 minutes

Avec l’APM Datadog, vous pouvez examiner les performances de vos endpoints, identifier les requêtes lentes et trouver l’origine des problèmes de latence. Cet exemple permet d’identifier la trace la plus lente de la journée pour un endpoint de paiement d’une plateforme e-commerce et d’attribuer l’origine de ce ralentissement à une charge processeur élevée.

  1. Ouvrez la page Services.

    Cette page affiche la liste de tous les services instrumentés disponibles dans l’APM Datadog. Notez que vous pouvez rechercher des mots clés, filtrer par env-tag et définir la chronologie.

  2. Recherchez un service web pertinent et actif, puis ouvrez la page Service.

    Cet exemple s’intéresse au service web-store, car il s’agit du serveur principal parmi l’ensemble des ressources et qu’il contrôle la plupart des appels aux services tiers.

    Identifier la trace la plus lente et identifier le goulot d'étranglement à son origine

    En plus d’afficher le débit, la latence et le taux d’erreur, la page Service contient une liste des ressources (opérations principales comme les endpoints d’API, les requêtes SQL et les requêtes web) identifiées pour le service.

  3. Triez le tableau des ressources selon la p99 latency (latence au 99e centile) et cliquez sur la ressource la plus lente. Remarque : si vous ne voyez pas la colonne p99 latency, cliquez sur l’icône en forme d’engrenage Change Columns et activez l’option p99.

    La page Ressource affiche les métriques de haut niveau sur cette ressource, telles que le débit, la latence et le taux d’erreur, ainsi que la répartition de la latence en fonction des différents services en aval de la ressource. De plus, elle affiche les traces spécifiques qui traversent la ressource et une vue agrégée des spans qui composent ces traces.

    Identifier la trace la plus lente et identifier le goulot d'étranglement à son origine
  4. Définissez le filtre d’intervalle sur 1d One Day. Faites défiler la page vers le bas jusqu’au tableau des traces et filtrez-le par durée. Ensuite, passez votre curseur sur la première trace dans le tableau et cliquez sur View Trace

    Le Flamegraph et des informations connexes apparaissent alors. C’est ici que vous pouvez consulter la durée de chaque étape dans la trace et vérifier la présence d’anomalies. Cela facilite l’identification des composants lents ou à l’origine d’un grand nombre d’erreurs. Vous pouvez agrandir, faire défiler et explorer le Flamegraph comme bon vous semble. Les métadonnées, les logs et les informations sur le host associés s’affichent sous le Flamegraph.

    Le Flamegraph est idéal pour identifier précisément quelle partie de votre stack est à l’origine d’erreurs ou d’une latence élevée. Les erreurs sont surlignées en rouge, et la durée est représentée par la longueur horizontale de la span. Les spans les plus longues sont donc les plus lentes. Consultez le guide sur la Vue Trace pour en savoir plus sur l’utilisation du Flamegraph.

    Sous le Flamegraph, la liste de tous les tags (y compris des tags custom) s’affiche. De là, vous pouvez également voir les logs associés (si vous avez connecté les logs à vos traces) et les informations sur le host, comme l’utilisation de la mémoire et du processeur.

    Identifier la trace la plus lente et identifier le goulot d'étranglement à son origine
  5. Cliquez sur l’onglet Host pour consulter les performances du processeur et de la mémoire du host sous-jacent au moment de la requête.

  6. Cliquez sur Open Host Dashboard pour consulter toutes les données pertinentes sur le host.

L’APM Datadog prend automatiquement en compte les autres informations et métriques de Datadog, telles que les métriques d’infrastructure et les logs. Le Flamegraph vous donne accès à ces informations ainsi qu’à toutes les métadonnées personnalisées que vous envoyez avec vos traces.

Pour aller plus loin

PREVIEWING: esther/docs-9478-fix-split-after-example