Page des traces

Lorsqu’une requête est lente et que vous devez voir où le temps a été passé, commencez par la page « Performance > Traces ». Cette page liste les actions pour lesquelles AppSignal a stocké des traces. Sélectionnez l’action que vous souhaitez examiner, puis sélectionnez l’une de ses traces stockées à un moment précis. La page de la trace montre cette requête, ce job ou cette tâche enregistrée en détail : ses services, ses spans, ses métadonnées, les erreurs et logs associés, et les autres traces de la même action. Utilisez la page pour répondre à trois questions pratiques :

• Quel service ou span a pris le temps ?
• La trace a-t-elle produit une erreur, et où a-t-elle commencé ?
• Quelles données de requête ou quels tags aident à expliquer cette exécution ?

L’en-tête affiche le nom de l’action et son namespace, par exemple run/shop.send_waitlist_notification dans celery/background. Les onglets sous l’en-tête permettent de basculer entre les vues de la même action : Summary, Traces, Charts et Logbook.

​

Carte des services

La carte des services montre la trace du point de vue des services impliqués : quels services la requête a atteints, et combien de temps a duré chaque appel entre eux. La carte des services n’apparaît que lorsqu’une trace s’étend sur deux services ou plus, par exemple lorsqu’une requête appelle un autre service via HTTP ou met en file d’attente une tâche en arrière-plan. Une requête qui reste à l’intérieur d’un seul service n’a pas de carte.

• Un bloc par service, regroupé par service_name. Chaque bloc est étiqueté avec le nom du service et l’application AppSignal à laquelle il rapporte. À l’intérieur, une ligne par appel traité par le service, de sorte qu’un service appelé deux fois dans la même trace affiche deux lignes. Sélectionnez une ligne pour ouvrir la propre vue de ce service sur la trace.
• Les arêtes sont les appels entre services, étiquetées avec leur durée et aboutissant sur la ligne d’action qu’elles ont appelée.
• Survolez ou mettez le focus sur une étiquette de durée pour voir sa répartition, lorsque l’appel a passé du temps en dehors du service appelé : la durée totale, la durée à l’intérieur du service appelé, et la latence entre les deux services.
• La couleur de l’arête évalue chaque appel par rapport à la référence propre de la trace, comme rapide, lent ou critique, afin que les appels les plus lents ressortent sans que vous ayez à lire chaque durée. Une arête en pointillés indique une trace liée, et un bloc en pointillés indique un service provenant d’une autre trace.
• Les erreurs marquent le service dans lequel elles se sont produites, et non le service qui l’a appelé.

Sélectionnez Fullscreen pour examiner l’ensemble de la carte et sa légende.

​

Erreurs de cette trace

Si la trace a produit des incidents d’exception, AppSignal affiche un tableau Errors from this trace au-dessus de la chronologie de la trace. Utilisez-le pour ouvrir la vue de trace d’erreur de cet incident dans la même trace, où vous pouvez examiner le message d’erreur, le backtrace et les causes de l’erreur.

​

Chronologie de la trace

La chronologie détaille les spans de la trace dans le temps, du début de la trace jusqu’à sa fin. La position de chaque barre montre quand un span a commencé, sa largeur montre combien de temps le span a duré, et sa couleur montre le groupe de spans auquel il appartient. Lorsqu’AppSignal détecte une requête N+1, la chronologie affiche une brève explication au-dessus des spans et marque le span représentatif d’un badge jaune. Sélectionnez le badge pour développer ce span et examiner les requêtes répétées. La chronologie suit l’opération à travers les services. Chaque service est étiqueté dans la chronologie, afin que vous puissiez voir où un service transmet le travail au suivant. Vous pouvez développer les lignes de la chronologie de la trace si la trace comporte plus de spans que n’en affiche cet aperçu, ou sélectionner All spans pour afficher la chronologie complète et ses fonctionnalités :

• Rechercher des spans par nom, attribut ou événement.
• Filtrer par type d’événement : errors, queries ou events.
• Filtrer par groupe de spans, comme serveur web, base de données et ORM, HTTP ou autre.
• Filtrer par service, ou restreindre la chronologie à une partie de la durée de la trace.
• Développer et réduire les spans imbriqués. Un badge indique le nombre de spans enfants d’un span, et un badge de répétition tel que x6 indique combien de fois le même span s’est exécuté.
• Sélectionner un span pour ouvrir ses détails.

​

Détails du span

Le panneau de détails nomme le span et indique son type, comme consumer, son statut, son heure de début et sa durée. Trois onglets fournissent le reste :

• Attributes : les attributs du span, comme celery.task_name et messaging.destination, ainsi que les attributs de ressource, comme host.name et service.name. Sélectionnez Show internal attributes pour lister également les attributs ajoutés par AppSignal. L’ID de la trace et l’ID du span ne sont visibles que lorsque Show internal attributes est sélectionné.
• Exceptions ou Events : les erreurs et autres événements enregistrés sur le span. Un span ayant déclenché une exception affiche aussi un résumé en haut du panneau, avec une action pour consulter l’exception.
• Related logs : les lignes de log liées au span. Sélectionnez View in logs pour continuer dans l’explorateur de logs. L’onglet Related logs s’ouvre avec sa portée réglée sur This span, il ne recherche donc que les lignes de log du span sélectionné. Réglez la portée sur Entire trace pour élargir la recherche à toutes les lignes de log liées à la trace, sur l’ensemble de ses spans et services.

​

Répartition de la trace

La répartition de la trace montre où le temps de la trace est passé, réparti entre les bibliothèques et le code qui ont effectué le travail, comme active_record, http_rb ou sidekiq. La légende liste chacune avec son total, la plus importante en premier. Certaines traces peuvent aussi afficher une barre Allocations indiquant combien d’objets chacune a alloués.

​

Metadata

La section Metadata indique quand la subtrace sélectionnée s’est produite, puis regroupe les métadonnées de cette subtrace dans des onglets. Chaque onglet n’apparaît que lorsqu’AppSignal a reçu ce type de données pour la subtrace sélectionnée. Lorsque des tags sont présents, l’onglet Tags apparaît en premier.

• Tags : les tags AppSignal sur la subtrace sélectionnée, ainsi que sa revision le cas échéant, comme hostname, queue, message_id et revision.
• Request headers : les en-têtes HTTP qu’AppSignal a reçus pour cette subtrace.
• Environment : les autres valeurs de requête que l’intégration a rapportées pour cette subtrace. Selon l’intégration, des valeurs semblables à des en-têtes peuvent aussi y apparaître.
• Request query parameters : les paramètres de la chaîne de requête qu’AppSignal a reçus pour cette subtrace, lorsqu’ils sont disponibles.
• Request payload : le corps de la requête qu’AppSignal a reçu pour cette subtrace, lorsqu’il est disponible.
• Request session data : les valeurs de session qu’AppSignal a reçues pour cette subtrace, lorsqu’elles sont disponibles.
• Custom data et Function parameters : le contexte supplémentaire ajouté par votre instrumentation pour cette subtrace.

Chaque tag dispose de deux actions :

• Filter restreint la liste des traces à celles de cette action qui portent la même valeur. La valeur reste visible au-dessus de la liste, et Reset la réinitialise.
• Search ouvre un aperçu de tout ce qu’AppSignal a enregistré avec cette valeur. Vous pouvez restreindre l’aperçu par application, namespace, période et type, afin de ne voir que les erreurs ou seulement les traces de performance qui la partagent. Sélectionnez Go to trace sur un résultat pour l’ouvrir.

Utilisez le filtrage des en-têtes, le filtrage des paramètres et le filtrage des données de session pour contrôler quelles valeurs de requête votre application envoie. Pour transformer une valeur de tag en lien vers votre propre application, utilisez les modèles de lien. Pour envoyer plus de tags depuis votre application, consultez le tagging.

​

Logs associés

L’encadré Related logs au niveau de la trace montre les lignes de log qu’AppSignal a pu lier à cette trace, avec leur heure, leur sévérité et leur message. Sélectionnez Open in the log view pour continuer dans l’explorateur de logs. Le panneau signale lorsqu’il ne trouve aucune ligne de log associée. AppSignal lie une ligne de log à une trace lorsque la ligne de log porte le request_id ou le trace_id de la trace en tant qu’attribut, ou contient cet identifiant dans son message. Le panneau reste vide lorsque l’opération n’a rien journalisé, lorsque votre application n’envoie pas encore de logs à AppSignal, ou lorsqu’aucune ligne de log ne porte l’identifiant. Consultez configurer la journalisation pour envoyer des logs, et lier les traces aux logs pour les identifiants.

​

Breadcrumbs

Si votre application enregistre des breadcrumbs AppSignal sous forme d’événements appsignal.breadcrumb, la page les affiche dans l’ordre chronologique sous Breadcrumbs. Chaque breadcrumb inclut son heure, sa catégorie, son action et, le cas échéant, un message et des métadonnées. Utilisez-les pour voir ce qui a mené à cette trace sans quitter la page.

​

Perf. trends

En haut de la colonne de droite, Perf. trends affiche la performance de l’action sur les dernières 24 heures ou 30 jours. Pour les traces de performance, le graphique trace le P90 et la durée moyenne. Sélectionnez 24H ou 30D pour changer la période, puis sélectionnez un point sur le graphique pour faire défiler la liste des traces jusqu’à ce moment.

​

Triggers

Les triggers vous alertent lorsque cette action devient lente. Le panneau liste les triggers déjà existants pour l’action, comme Mean > 200 ms. S’il n’y en a pas encore, la case affiche No triggers yet et un lien Add new. Sélectionnez Add new pour ouvrir le formulaire de trigger avec le namespace et le nom de l’action déjà renseignés. Dans le formulaire, vous :

• Choisissez la valeur sur laquelle alerter, comme la moyenne, et le seuil au-delà duquel AppSignal alerte, comme 200 ms.
• Définissez un warm-up et un cooldown d’alerte en minutes.
• Ajoutez une description pour les personnes qui reçoivent l’alerte.
• Sélectionnez les notifiers qui la reçoivent, comme e-mail, Slack, PagerDuty ou OpsGenie.

Les triggers existants indiquent aussi s’ils ont des alertes ouvertes, la date de leur dernier déclenchement, et un menu pour les modifier, les dupliquer ou les supprimer. Pour savoir comment les alertes s’ouvrent, se ferment et se répètent, consultez Anomaly detection et warm-up et cooldown.

​

Actions

La case Actions vous propose deux types de suivi :

• Time detective : examinez les données de votre application telles qu’elles étaient au moment de la trace.
• JSON and Markdown exports : téléchargez ou copiez la trace dans l’un ou l’autre format. L’export Markdown inclut le résumé de la trace, les erreurs associées, l’arborescence des spans, la répartition, les métadonnées partagées telles que les données de session et l’environnement, les breadcrumbs et le contexte.

​

Traces

Le panneau Traces liste les autres traces enregistrées pour cette action, chacune avec son horodatage et sa durée. Sélectionnez-en une pour l’ouvrir. Pour trouver une trace précise :

• Saisissez une valeur dans le champ de filtre de tag, ou utilisez l’action Filter sur un tag, pour ne conserver que les traces portant cette valeur.
• Ouvrez le sélecteur de date pour choisir une date et une heure, ou choisissez Today, Yesterday, Last week ou Latest. Sélectionnez Jump to date ou Jump to latest pour mettre à jour la liste.
• Sélectionnez Load newer traces ou Load older traces pour parcourir la liste.
• Sélectionnez Reset pour effacer les filtres et revoir toutes les traces enregistrées.

Un marqueur de déploiement entre deux traces montre où une nouvelle version a pris le relais, ce qui vous aide à comparer les traces d’avant et d’après un déploiement.

​

Logbook

Les traces expirent, et avec elles le contexte que votre équipe a rassemblé en enquêtant sur l’une d’elles. Le logbook conserve ce contexte au niveau de l’action à la place. Chaque action sur la page « Performance > Traces » possède un logbook, partagé par toutes ses traces. Une note que vous écrivez aujourd’hui est toujours là lorsque la prochaine trace lente de cette action arrive. Pour ouvrir le logbook, sélectionnez l’action sur la page « Performance > Traces ». Cela ouvre l’onglet Summary de l’action, qui contient un encadré Logbook avec le formulaire de note et les notes déjà écrites. Rédigez votre note et sélectionnez Post note. Elle apparaît dans l’encadré, sous la note épinglée s’il y en a une. Sélectionnez Full logbook, ou l’onglet Logbook, pour ouvrir le logbook complet sur sa propre page. Les notes prennent en charge le Markdown. Vous pouvez épingler n’importe quelle note pour la garder en haut, et épingler une autre note remplace la précédente. Vous ne pouvez modifier et supprimer que les notes que vous avez écrites. Un logbook de trace ne contient que des notes. Contrairement au logbook d’un incident, il n’enregistre pas les changements d’état et ne lie pas d’issues GitHub. Pour un agent, l’outil manage_note du MCP AppSignal ajoute et modifie ces notes par namespace et nom d’action. L’API GraphQL fait de même avec la mutation createPerformanceTraceActionNote. Une fois que vous avez noté un correctif, ajoutez un trigger dans le panneau Triggers. AppSignal vous alerte alors si l’action redevient lente.