> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Page des traces
> Examinez une trace : sa carte des services, sa chronologie des spans, les détails des spans, les tags, les logs associés, les triggers et les autres traces de la même action.
Lorsque vous choisissez une trace à examiner dans la liste [« Performance > Traces »](https://appsignal.com/redirect-to/app?to=performance/traces) et que vous sélectionnez l'une des dernières traces à un moment précis, vous accédez à la page de détail des traces de performance, qui affiche la carte des services de la trace, sa chronologie, ses tags et ses logs associés.
La page de la trace montre une trace enregistrée pour une action : une requête, une tâche en arrière-plan ou une autre opération effectuée par votre application. Une trace est composée de **spans**, les unités de travail individuelles qui la composent, comme une requête HTTP, une requête de base de données ou une tâche en arrière-plan.
Utilisez cette page pour voir où l'opération a passé son temps, examiner son contexte et ses logs, et décider de la suite à donner.
L'en-tête affiche le nom de l'action et son [namespace](/guides/namespaces), 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 et Charts.
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. Elle n'apparaît que lorsqu'une trace traverse plus d'un service, car une trace qui reste à l'intérieur d'un seul service n'a rien à cartographier.
* **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. Cela couvre les appels synchrones, comme une requête HTTP, et les appels asynchrones, comme une application web mettant en file d'attente une tâche en arrière-plan.
* **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 sauts 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é.
La légende explique chaque couleur et chaque bordure, et vous pouvez la réduire pour voir davantage de la carte.
Chronologie de la trace
Lorsque vous sélectionnez une trace à un moment précis, la chronologie dispose 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. AppSignal signale aussi les problèmes ici, comme un événement N+1 : la même requête répétée de nombreuses fois dans une seule opération.
La chronologie suit l'opération à travers les services. Dans une boutique de stroopwafels, une requête Django peut mettre en file d'attente une tâche Celery, la tâche envoie un e-mail, et un service d'audit enregistre le résultat. Chaque service est étiqueté dans la chronologie, afin que vous puissiez voir où un service transmet le travail au suivant.
Sélectionnez **All spans** pour ouvrir la chronologie en plein écran, où vous pouvez :
* Rechercher des spans par nom, attribut ou événement.
* Filtrer par type d'événement : errors, queries ou events.
* Filtrer par issue, comme les requêtes N+1.
* 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](/logging).
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 résume l'ensemble de la trace en deux barres empilées. Dans les deux, chaque segment correspond à l'une des bibliothèques ayant effectué le travail, comme `active_record`, `http_rb` ou `sidekiq`, et la légende liste chaque bibliothèque avec son propre total, la plus importante en premier.
* **Durations** : la part du temps de la trace attribuable à chaque bibliothèque.
* **Allocations** : le nombre d'objets alloués par chaque bibliothèque, avec le total de la trace dans l'en-tête.
Les tags sont les paires clé-valeur enregistrées avec la trace, comme `hostname`, `queue`, `message_id` et `revision`.
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.
Pour transformer une valeur de tag en lien vers votre propre application, utilisez les [modèles de lien](/application/link-templates). Pour envoyer plus de tags depuis votre application, consultez [le tagging](/application/tagging).
Les lignes de log liées à cette trace, avec leur heure, leur sévérité et leur message. Dans l'exemple des stroopwafels, elles montrent le démarrage de la tâche de liste d'attente, l'échec de l'envoi de l'e-mail, et la nouvelle tentative qui suit. Sélectionnez **Open in the log view** pour continuer dans l'[explorateur de logs](/logging).
Le panneau signale lorsqu'il ne trouve aucune ligne de log associée. AppSignal lie une ligne de log à une trace via un `request_id` ou un `trace_id` partagé, donc le panneau reste vide lorsque l'opération n'a rien journalisé, lorsque votre application n'envoie pas encore de logs à AppSignal, ou lorsque l'identifiant manque à l'un des deux. Consultez [configurer la journalisation](/logging/configuration) pour envoyer des logs, et [lier les traces aux logs](/guides/linking-traces-with-logs) pour les identifiants.
Détails de la requête
Pour les requêtes web, la page affiche aussi les données brutes reçues par AppSignal, dans trois panneaux :
* **En-têtes de requête** : les en-têtes HTTP envoyés avec la requête. Utilisez le [filtrage des en-têtes](/application/header-filtering) pour choisir les en-têtes que votre application envoie.
* **Payload de la requête** : le corps de la requête, comme une requête GraphQL et ses variables. Utilisez le [filtrage des paramètres](/application/parameter-filtering) pour tenir les valeurs sensibles à l'écart.
* **Données de session de la requête** : les valeurs de session de la requête. Utilisez le [filtrage des données de session](/application/session-data-filtering) pour tenir les valeurs sensibles à l'écart.
Un graphique de la performance de l'action sur les dernières 24 heures ou 30 jours.
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é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.
Pour savoir comment les alertes s'ouvrent, se ferment et se répètent, consultez [Anomaly detection](/anomaly-detection) et [warm-up et cooldown](/anomaly-detection#warm-up-and-cooldown).
Actions
* **Time Detective** : examinez les données de votre application telles qu'elles étaient au moment de la trace.
* **Send to your issue tracker** : créez une issue à partir de la trace. Cette action apparaît lorsqu'un tracker est connecté, et son libellé correspond à ce tracker, comme GitHub, GitLab, Jira ou Linear. Consultez [les intégrations](/application/integrations).
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 latest** pour revenir aux traces les plus récentes.
* 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](/application/markers) 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.
AppSignal ne conserve pas une trace pour chaque requête. Il en stocke un ensemble représentatif à la place, de sorte que la liste montre un échantillon du trafic de l'action.