Comprendre et utiliser l'UI de tracing distribué

La barre de requête Find traces est un moyen rapide d'affiner votre recherche de trace. Vous pouvez commencer à taper dans la barre de requête ou utiliser la liste déroulante pour créer une requête composée.

les retours de requête sont basés sur l'attribut span, et non sur l'attribut trace . Vous définissez des étendues qui ont certains critères et la recherche affiche les traces qui contiennent ces étendues.

Si vous utilisez un filtre multi-attributs, il est affecté par le premier attribut sélectionné. Rapports des tracing distribués sur deux types de données : transaction événement et spans. Lorsque vous sélectionnez un attribut dans le filtre, le type de données auquel cet attribut est attaché dicte l'attribut disponible. Par exemple, si vous filtrez sur un attribut attaché à un événement de transaction, seul l'attribut d'événement de transaction est disponible lorsque vous tentez d'ajouter un filtre sur des valeurs d'attribut supplémentaires.

Les requêtes de trace sont similaires à NRQL (notre langage de requête), à quelques exceptions près :

• Les valeurs de chaîne ne nécessitent pas de guillemets (par exemple, vous pouvez utiliser appName = MyApp ou appName = 'MyApp')

• L'opérateur like ne nécessite pas % (par exemple, vous pouvez utiliser appName like product ou appName like %product%).

  Voici deux exemples d’utilisation de la barre de requête :

  Trouver des traces qui touchent deux services<>Rechercher les plages d'erreur à l'aide de l'opérateur <InlineCode>like</InlineCode> </>

  Trouver des traces qui touchent deux services

  <>Rechercher les plages d'erreur à l'aide de l'opérateur <InlineCode>like</InlineCode> </>

  La requête dans l'image ci-dessous trouve une trace de :

  1. Passer par les applications WebPortal et Inventaire Service

  2. Avoir un appel datastore Inventory Service qui prend plus de 500 ms

  3. Contient une erreur dans n'importe quelle étendue.

     

  La requête dans l'image ci-dessous trouve une trace de :

  1. Contient les étendues qui passent par l'application WebPortal et où une erreur s'est produite sur n'importe quelle étendue de l'application WebPortal

  2. Contient les étendues où l'attribut customer_user_email contient une valeur se terminant par hotmail.com n'importe où dans la trace.

     

Outre la barre de requête en haut de la page, vous pouvez utiliser une variété de filtres dans le volet de gauche pour trouver la trace qui vous intéresse.

• Infinite tracing data:Sélectionnez cette option uniquement pour afficher la trace liée à la fonctionnalité Infinite Tracing.

• Multi span traces only:Utilisez ceci pour masquer la trace à portée unique.

• Error filters:Sous Errors sélectionnez les erreurs à filtrer.

• Histogram filters:En dessous de Errors en bas du volet de gauche, vous pouvez cliquer sur More filters pour afficher les filtres d'histogramme. Faites glisser les curseurs pour modifier les valeurs, telles que Trace duration:

  • Faites glisser l'extrémité gauche du curseur pour des comparaisons supérieures à.
  • Faites glisser l'extrémité droite du curseur pour les comparaisons inférieures à.
  • Faites glisser chaque extrémité du curseur vers le centre pour filtrer par une plage.
  

La vue par défaut du tracing distribué affiche les traces regroupées par la même étendue d'entrée racine. En d’autres termes, les traces sont regroupées en fonction de la période à laquelle New Relic a commencé à enregistrer la demande. Vous pouvez faire glisser le bouton Group similar traces pour activer et désactiver cette fonction.

Avec les groupes trace vous obtenez une vue d'ensemble des traces afin de comprendre le comportement des demandes pour les groupes de traces similaires. Cela vous aide à comprendre les baisses ou les pics dans le nombre trace, la durée et les erreurs. Lorsque vous cliquez sur l’un des groupes trace, vous obtenez tous les détails standard dans le contexte du groupe trace spécifique que vous avez sélectionné.

Si Group similar traces est activé, vous verrez trois graphiques en haut de la page dans le tracing distribué. Ces graphiques vous montrent le nombre trace, la durée du 95e percentile et le nombre d'erreurs pour chacun des groupes trace répertoriés dans le tableau sous les graphiques. Pour modifier les filtres sur ces graphiques, consultez les filtres du volet de gauche.

Le nuage de points de trace est un moyen rapide de rechercher des traces aberrantes. Ceci est disponible sur la page d'ouverture du tracing distribué si vous désactivez la bascule Group similar traces en haut de la page.

Dans le nuage de points, vous pouvez déplacer le curseur sur le graphique pour afficher les détails de la trace et vous pouvez cliquer sur des points individuels pour obtenir des détails :

Contrôler ce qui est affiché dans le nuage de points :

1. Sélectionnez le type de durée dans la liste déroulante View by :

• Backend duration

• Root span duration

• Trace duration

2. Dans Facet traces by, sélectionnez l’une de ces options :

• Root entry span: Regroupez par la transaction racine, qui est le point de terminaison du service racine. Dans une trace où le service A appelle le service B et le service B appelle le service C, l'étendue de l'entrée racine est le point de terminaison du service A. Par exemple : "Service A - GET /utilisateur/%".
• Root entity:Grouper par le nom de la première entité dans la trace. Dans une trace où le service A appelle le service B et le service B appelle le service C, l'entité racine serait le service A.
• Errors: Regrouper selon que la trace contient ou non des erreurs.

3. Pour obtenir des conseils sur la façon de modifier les filtres du nuage de points, consultez les filtres du volet de gauche.

Les erreurs au niveau de l'étendue vous montrent où les erreurs ont été générées dans un processus, comment elles ont surgi et où elles ont été traitées. Chaque étendue qui se termine par une erreur est affichée avec une erreur dans l'UI et contribue au nombre total d'erreurs pour cette trace.

Voici quelques conseils généraux pour comprendre les erreurs d’étendue :

• Les étendues contenant des erreurs sont surlignées en rouge dans l'UI de tracing distribué. Vous pouvez voir plus d’informations dans le volet Error Details pour chaque plage.

• Toutes les étendues qui sortent avec des erreurs sont comptabilisées dans le nombre d'erreurs d'étendue.

• Lorsque plusieurs erreurs se produisent sur la même plage, une seule est écrite dans la plage dans cet ordre de priorité :

  • UN noticeError
  • L'erreur d'étendue la plus récente dans le cadre de cette étendue

  Ce tableau décrit comment les différentes erreurs d'étendue sont gérées :

  Type d'erreur	Description
  Travées se terminant par des erreurs	Une erreur qui quitte la limite d'une étendue entraîne une erreur sur cette étendue et sur toutes les étendues ancêtres qui sortent également avec une erreur, jusqu'à ce que l'erreur soit détectée ou quitte la transaction. Vous pouvez voir si une erreur est détectée dans une étendue d'ancêtre.
  Remarquez les erreurs	Les erreurs constatées par les appels à l'API de l'agent noticeError ou par l' instrumentation automatique de l'agent sont attachées à la plage en cours d'exécution.
  Erreurs de code de réponse	Les erreurs de code de réponse sont attachées à l'étendue associée, telles que : client span : transactions externes préfixées par http ou db. Portée de la saisie : Dans le cas d'une transaction se terminant par une erreur de code de réponse. Le code de réponse pour ces plages est capturé en tant qu’attribut http.statusCode et attaché à cette plage.
  Erreurs OpenTelemetry	La zone Error Details du volet de droite est remplie par des étendues contenant otel.status_code = ERROR et affiche le contenu de otel.status_description. Conseil Les événements d'étendue OpenTelemetry gérés par l'application/le service sont affichés indépendamment de l'état d'erreur d'étendue et ne sont pas nécessairement associés à un état d'erreur d'étendue. Vous pouvez afficher les exceptions et non-exceptions des événements SPAN en cliquant sur View span events dans le volet de droite.

Si une plage est affichée comme anormale dans l'UI, cela signifie que les deux conditions suivantes sont vraies :

• La durée est plus lente de plus de deux écarts types que la moyenne de toutes les durées portant le même nom et provenant du même service au cours des six dernières heures.
• La durée de la période est supérieure à 10 % de la durée de la trace.

Lorsqu'un processus appelle un autre processus et que les deux processus sont instrumentés par New Relic, la trace contient à la fois une représentation côté client de l'appel et une représentation côté serveur. Le client span (processus appelant) peut avoir des différences liées au temps par rapport au serveur span (processus appelé). Ces différences pourraient être dues à :

• Décalage d'horloge, dû aux différences d'heure de l'horloge système

• Différences de durée, dues à des facteurs tels que la latence du réseau ou le délai de résolution DNS

  L'UI montre ces différences liées au temps en affichant un aperçu de l'étendue du client dans le même espace que l'étendue du serveur. Cette plage représente la durée du client.

  Il n'est pas possible de déterminer tous les facteurs contribuant à ces écarts liés au temps, mais voici quelques modèles courants de durée de vie et des conseils pour les comprendre :

  

  A. Lorsqu'un client SPAN est plus long que le serveur SPAN, cela peut être dû à une latence dans un certain nombre de domaines, tels que : le temps réseau, le temps de file d'attente, le temps de résolution DNS ou un équilibreur de charge que nous ne pouvons pas voir. B. Lorsqu'un client SPAN démarre et se termine avant le début d'un SPAN de serveur, cela peut être dû à un décalage d'horloge ou au fait que le serveur effectue un travail asynchrone qui continue après l'envoi de la réponse. C. Lorsqu'un client SPAN démarre après un SPAN de serveur, il s'agit probablement d'un décalage d'horloge.

Les traces fragmentées sont des traces avec des étendues manquantes. Lorsqu'un span est manquant ou possède des identifiants parents de span non valides, son span enfant est séparé du reste de la trace, ce que nous appelons « orphelin ». Les étendues orphelines apparaissent au bas de la trace et elles manqueront de lignes de connexion au reste de la trace. Si vous avez des étendues fragmentées, vous verrez le mot Fragmented en haut de la page de détails :

Types de propriétés span orphelines indiquées dans l'UI:

• No root span. Il manque la portée racine, qui est la première opération de la requête. Lorsque cela se produit, la plage avec l’horodatage le plus ancien est affichée comme racine.

• Orphaned span. Une seule étendue avec un parent d'étendue manquant. Cela peut être dû au fait que le parent span possède un ID qui ne correspond pas à son enfant span.

• Orphaned trace fragment. Un groupe de travées connectées où la première travée du groupe est une travée orpheline.

  Cela peut se produire pour plusieurs raisons, notamment :

• Collection limits. Certaines applications à haut débit peuvent dépasser les limites de collecte (par exemple, les limites de collecte de l'agent APM ou les limites de l'API). Lorsque cela se produit, il peut en résulter une trace comportant des étendues manquantes. Une façon de remédier à cela est de désactiver certains rapports, afin que la limite ne soit pas atteinte.

• Incorrect instrumentation. Si une application est instrumentée de manière incorrecte, elle ne passera pas correctement le contexte de trace et cela entraînera une trace fragmentée. Pour remédier à ce problème, examinez la source de données qui génère des étendues orphelines pour vous assurer que l’instrumentation est effectuée correctement. Pour découvrir la source de données d'une étendue, sélectionnez-la et examinez ses détails.

• Spans still arriving. Si certains parents de span n'ont pas encore été collectés, cela peut entraîner des lacunes temporaires jusqu'à ce que la trace entière soit signalée.

• UI display limits. Des étendues orphelines peuvent survenir si une trace dépasse la limite d'affichage d'étendue de 10 K.

Les traces préservées sont similaires aux instantanés de la trace originale. Ils archivent une trace complète qui a été précédemment consultée et qui a dépassé la période de conservation. Les traces complètes ne sont disponibles que pendant 7 jours, sauf si vous avez acheté une conservation prolongée (qui se refléterait automatiquement dans l'UI). Cependant, une trace préservée peut exister jusqu'à 1 an et fonctionne généralement comme la trace originale.

Notez que la trace préservée n'affichera pas les données de performances de portée ni les données d'anomalie de portée. La trace conservée peut ne pas être accessible si une entité dans une trace conservée est supprimée, expire ou cesse de signaler des données.

Si vous n'avez pas accès aux comptes New Relic qui monitorent d'autres services, certains détails de durée et de service seront masqués dans l'UI. L'obfuscation peut inclure :

• Nom de la portée masqué par des astérisques

• Le nom du service a été remplacé par l'ID de compte New Relic et l'ID d'application

  Pour plus d'informations sur les facteurs affectant votre accès aux comptes, voir Accès au compte.

Voir Agents linguistiques : échantillonnage adaptatif.

Lors de l'affichage de la cascade de travées, les noms de travées peuvent être affichés sous une forme incomplète qui est plus lisible par l'homme que le nom de travée complet. Pour trouver le nom complet, sélectionnez cette plage et recherchez le Full span name. Connaître le nom complet peut être utile pour interroger ces données avec NRQL.

Une trace peut parfois avoir (ou sembler avoir) des étendues ou des services manquants. Cela peut se manifester par une différence entre le nombre d'étendues ou de services d'une trace affichés dans la liste des traces et le nombre affiché sur la page des détails de la trace .

Les raisons des écarts de portée manquants et des écarts de comptage incluent :

• Un agent APMa peut-être atteint sa limite de collecte de portée.

• Une étendue peut être initialement comptée mais ne pas être affichée dans un affichage de trace, pour des raisons telles que la latence du réseau ou un problème de requête.

• L'UI a peut-être atteint sa limite d'affichage de 10 000.

  Toutes les étendues collectées, y compris celles non affichées, peuvent être interrogées avec NRQL.