Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
Tracing distribué vous aide à monitorer et analyser le comportement de vos systèmes distribués. Après avoir activé le tracing distribué, vous pouvez utiliser nos outils UI pour rechercher des traces et les analyser.
Si vous cherchez à résoudre des erreurs dans une transaction qui couvre plusieurs services :
Triez votre trace à l'aide d'un filtre pour trouver cette demande spécifique et afficher uniquement la trace contenant des erreurs.
Sur la page des détails de la trace, examinez la span le long de l’itinéraire de demande à l’origine de l’erreur.
En notant la classe d’erreur et le message, accédez au service à partir de sa span dans la trace afin de voir que l’erreur se produit à un rythme élevé.
Conseil
Working with asynchronous traces?
Si vos traces sont divisées en plusieurs limites asynchrones, telles que des files d'attente de messages ou des flux d'événements, vous pouvez utiliser les liens de span pour naviguer entre les traces liées de manière causale. Les liens de span vous aident à comprendre le flux complet des requêtes, même lorsque les traces sont déconnectées. Apprenez-en davantage sur la compréhension des liens de span.
Lisez la suite pour explorer les options de l’ UI de tracing distribué.
Nous disposons d'une variété d'outils pour vous aider à trouver des traces et des spans afin que vous puissiez résoudre les problèmes. La page d'ouverture de tracing distribué est remplie avec une liste de traces par défaut. Vous pouvez rapidement affiner cette liste à l'aide de ces outils :
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 spans qui ont certains critères et la recherche affiche les traces qui contiennent ces spans.
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 :
La requête dans l'image ci-dessous trouve une trace de :
Passer par les applications WebPortal et Inventaire Service
Avoir un appel datastore Inventory Service qui prend plus de 500 ms
En plus de la barre de requête en haut de la page, vous pouvez utiliser les pastilles de filtre intégrées, et les boutons bascules pour affiner votre liste de traces.
Entities: utilisez la liste déroulante des entités pour filtrer les traces par entités spécifiques dans votre système.
Errors: sélectionnez cette pastille pour afficher uniquement les traces qui contiennent des erreurs.
Refine: cliquez sur Refine à droite de la barre de filtre pour accéder à des options de filtrage supplémentaires.
Unfragmented traces only: activez cette option pour masquer les traces fragmentées et afficher uniquement les traces complètes.
Multi-span only: activez ce commutateur pour masquer les traces à span unique et afficher uniquement les traces avec plusieurs spans.
Organisez vos données de span
L'onglet Trace groups est la vue par défaut du tracing distribué. Il regroupe les traces en fonction de leur période d'entrée racine, la période à laquelle New Relic a commencé à enregistrer la demande.
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é.
Lorsque vous êtes sur l'onglet Trace groups, vous verrez trois graphiques récapitulatifs en haut de la page : Trace count, Trace duration (ms), et Error rate. Chaque graphique est ventilé par groupe de traces. Sous les graphiques, un tableau répertorie les principaux groupes par nombre de traces avec des colonnes pour les traces, les spans moyens, les entités moyennes, la durée du span racine, et les erreurs.
Le nuage de points de trace est un moyen rapide de rechercher des traces aberrantes. Il est disponible lorsque vous sélectionnez l'onglet Root entry span, Root entity, ou Errors en haut de la liste de traces.
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 :
Sélectionnez le type de durée dans la liste déroulante View by :
Backend duration
Root span duration
Trace duration
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, la span 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.
Pour affiner davantage les traces affichées dans le nuage de points, utilisez les pastilles de filtre en ligne et les commutateurs situés en haut de la page.
Conseil
Certaines requêtes produisant de nombreux résultats peuvent entraîner des faux positifs dans les graphiques. Cela peut se manifester par des graphiques affichant des résultats de trace qui ne figurent pas dans la liste de trace.
Détails supplémentaires UI
Voici quelques détails, règles et limites supplémentaires relatifs UI distribuée en matière de tracing :
Les erreurs au niveau de la span 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 span 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 de span :
Les spans 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 spans qui sortent avec des erreurs sont comptabilisées dans le nombre d'erreurs de span.
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 de span la plus récente dans le cadre de cette span
Ce tableau décrit comment les différentes erreurs de span sont gérées :
Type d'erreur
Description
Travées se terminant par des erreurs
Une erreur qui quitte la limite d'une span entraîne une erreur sur cette span et sur toutes les span 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 span 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 à la span associée, telles que :
client span : transactions externes préfixées par http ou db.
Span d'entrée : 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 spans contenant otel.status_code = ERROR et affiche le contenu de otel.status_description.
Conseil
Les événements de span OpenTelemetry gérés par l'application/le service sont affichés indépendamment de l'état d'erreur de span et ne sont pas nécessairement associés à un état d'erreur de span. 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 la span du client dans le même espace que la span 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 spans 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 spans orphelines apparaissent au bas de la trace et elles manqueront de lignes de connexion au reste de la trace. Si vous avez des spans 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 span racine, qui est la première opération de la requête. Lorsque cela se produit, la span avec l'horodatage le plus ancien est affichée comme racine.
Orphaned span. Une seule span avec un parent de span 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 spans 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 spans orphelines pour vous assurer que l’instrumentation est effectuée correctement. Pour découvrir la source de données d'une span, 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 spans orphelines peuvent survenir si une trace dépasse la limite d'affichage de span 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 les traces conservées n'afficheront pas les données de performance de span ni les données d'anomalie de span. Les traces préservées peuvent ne pas être accessibles si une entité dans une trace préservé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 span 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.
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 spans ou des services manquants. Cela peut se manifester par une différence entre le nombre de spans 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 spans manquantes et des différences de nombre incluent :
Une span 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 spans collectées, y compris celles non affichées, peuvent être interrogées avec NRQL.
