Détails techniques du tracing distribué

Voici quelques détails techniques sur le fonctionnement du tracing distribué New Relic :

Comment fonctionne l'échantillonnage de traces
Comment nous structurons les données de trace
Comment nous stockons les données de trace
Comment le contexte de trace est transmis entre les applications

échantillonnage de traces

La manière dont vos traces sont échantillonnées dépendra de votre configuration et de l'outil de tracing New Relic que vous utilisez. Par exemple, vous pouvez utiliser un service de télémétrie tiers (comme OpenTelemetry) pour implémenter l'échantillonnage des traces avant que vos données ne nous parviennent. Ou, si vous utilisez Infinite Tracing, vous nous enverriez probablement toutes vos données de trace et vous vous fieriez à notre échantillonnage.

Nous avons quelques stratégies d'échantillonnage disponibles :

Échantillonnage en début de workflow (standard tracing distribué)
Échantillonnage en fin de workflow (Infinite Tracing)
Pas d'échantillonnage

Échantillonnage en début de workflow (standard tracing distribué)

À l’exception de notre fonctionnalité Infinite Tracing, la plupart de nos outils de tracing utilisent une approche d’échantillonnage en début de workflow. Cela applique des filtres aux étendues individuelles avant que toutes les étendues d'une trace n'arrivent, ce qui signifie que les décisions concernant l'acceptation des étendues sont prises au début (la « tête ») du processus de filtrage. Nous utilisons cette stratégie d’échantillonnage pour capturer un échantillon représentatif de l’activité tout en évitant les problèmes de stockage et de performances.

Une fois que la première plage d’une trace arrive, une session est ouverte et maintenue pendant 90 secondes. À chaque arrivée ultérieure d'une nouvelle plage pour cette trace, le délai d'expiration est réinitialisé à 90 secondes. les traces qui n'ont pas reçu de span au cours des 90 dernières secondes seront automatiquement fermées. Le résumé de la trace et les données d'étendue ne sont écrits que lorsqu'une trace est fermée.

Voici quelques détails sur la façon dont l'échantillonnage en début de workflow est implémenté dans nos outils de tracing distribué standard :

Nos agents linguistiques utilisent l’échantillonnage adaptatif pour capturer un échantillon représentatif de l’activité du système. Ce qui suit est une explication du fonctionnement de l’échantillonnage adaptatif.

Le débit du premier service d'une trace est utilisé pour ajuster la fréquence d'échantillonnage requests . Ceci est expliqué plus en détail ci-dessous, et vous pouvez également consulter la documentation de votre agent APM.

Le premier service que nous monitorons dans une tracedistribuée s'appelle la trace d'origine. L'origine trace choisit au hasard requests à tracer. Cette décision se propage aux services en aval concernés par cette demande. Une fois la demande terminée, les intervalles générés par ces requests sont signalés à New Relic et mis à disposition dans l'UI sous forme de trace complète (bien que les limites d'intervalle de l'agent décrites ci-dessous puissent entraîner une trace fragmentée).

Le service d'origine trace échantillonne 10 traces par minute par défaut. Il tente d'étaler la collecte de ces 10 traces sur une minute afin d'obtenir un échantillon représentatif dans le temps. Le taux d'échantillonnage exact dépend du nombre de transactions au cours de la minute précédente et s'adapte aux changements de débit des transactions.

Par exemple, s’il y a eu 100 transactions au cours de la minute précédente, l’agent anticiperait un nombre similaire de transactions et sélectionnerait 1 transaction sur 10 à échantillonner au cours de la minute suivante.

Les agents APM ont une limite sur le nombre d'intervalles collectés par minute, avec une limite par défaut de 2 000 intervalles collectés par minute par instance d'agent (pour savoir comment ajuster cela, consultez la documentation de configuration de l'agent APM). Si un agent génère plus de plages que sa limite configurée en une minute, certaines de ces plages seront supprimées, ce qui entraînera une trace fragmentée dans l'UI. Les traces se voient attribuer une priorité aléatoire lorsqu'elles sont sélectionnées pour l'échantillonnage. Ainsi, si plusieurs agents doivent supprimer des étendues, ils peuvent tenter de conserver intactes les traces de priorité supérieure en supprimant d'abord les étendues des traces de priorité inférieure.

Échantillonnage en fin de workflow (Infinite Tracing)

Notre fonctionnalité Infinite Tracing utilise une approche d’échantillonnage en fin de flux de travail. « Échantillonnage en fin de workflow » signifie que les décisions de conservation tracesont prises à la fin du traitement, une fois que toutes les traces d'une trace sont arrivées.

Avec Infinite Tracing, vous pouvez nous envoyer 100 % de vos données de trace depuis votre application ou un service de télémétrie tiers, et Infinite Tracing déterminera quelles données de trace sont les plus importantes. Et vous pouvez configurer l'échantillonnage pour garantir que les traces importantes pour vous sont conservées.

Important

Étant donné qu'Infinite Tracing peut collecter et transmettre davantage de données de trace à partir de votre application ou d'un service de télémétrie tiers, vous constaterez peut-être que vos coûts de sortie augmentent en conséquence. Nous vous recommandons de garder un œil sur ces coûts lors du déploiement d’Infinite Tracing pour vous assurer que cette solution vous convient.

Pour l'Infinite Tracing, les agents ou l'intégration envoient 100 % de toutes les étendues instrumentées à un observateur de trace. L'observateur de trace est un service de tracing distribué résidant dans un cluster de services sur AWS appelé New Relic Edge.

Conseil

Seules vos étendues sont transmises à l'observateur de trace : toutes les autres données telles que les métriques, les événements personnalisés et les traces de transaction sont envoyées par la voie normale vers New Relic et sont soumises à un échantillonnage local.

Vous configurez un point de terminaison d’observateur de trace unique pour la région AWS vers laquelle vous souhaitez envoyer des données. Étant donné que le tracing est une fonctionnalité inter-comptes, notre implémentation par défaut consiste à n'autoriser qu'un seul observateur de trace par région et par famille de comptes (pour en demander plus, parlez-en à votre représentant de compte). Le point de terminaison représente un observateur de trace pour une workload particulière. Par exemple, toutes les étendues d’une seule trace (requête) doivent atteindre ce point de terminaison.

Voici deux diagrammes d'architecture : l'un montrant comment les données circulent si vous utilisez des agents et l'autre si vous utilisez l'intégration New Relic comme l'exportateur OpenTelemetry :

Here are two diagrams showing the flow of data: one for agents and another for integrations with Infinite Tracing.

L'observateur de trace maintient la trace ouverte pendant que les intervalles pour cette trace arrivent. Une fois que la première plage d’une trace arrive, une session est maintenue ouverte pendant 10 secondes. Chaque fois qu'une nouvelle plage pour cette trace arrive, le délai d'expiration est réinitialisé à 10 secondes. les traces qui n'ont pas vu de span arriver au cours des 10 dernières secondes expireront automatiquement.

Par défaut, chaque observateur de trace propose une trace à trois échantillonneurs : l'un recherche une valeur de durée hors norme, l'autre recherche une trace avec des erreurs et l'autre tente d'échantillonner de manière aléatoire tous les types trace . Chaque échantillonneur conserve un pourcentage cible de traces correspondant à ses critères.

Voici les détails sur chaque échantillonneur :

Échantillonneur	Critères de correspondance	Pourcentage cible
Durée	tracer avec une durée valeur hors norme, à l'aide de deux algorithmes : Gaussien (suppose une distribution normale et un seuil au 99e percentile) Excentricité (suppose l'absence de distribution et un seuil basé sur le cluster)	100%
Erreur	trace ayant au moins une étendue avec une erreur	100%
Aléatoire	Toutes les traces	1% (Ceci est configurable. Voir Infinite Tracing : filtre de trace aléatoire)

Échantillonneur

Critères de correspondance

Pourcentage cible

Durée

tracer avec une durée valeur hors norme, à l'aide de deux algorithmes :

Gaussien (suppose une distribution normale et un seuil au 99e percentile)
Excentricité (suppose l'absence de distribution et un seuil basé sur le cluster)

100%

Erreur

trace ayant au moins une étendue avec une erreur

100%

Aléatoire

Toutes les traces

1% (Ceci est configurable. Voir Infinite Tracing : filtre de trace aléatoire)

Si les critères de correspondance correspondent à la trace, chaque échantillonneur examine la forme de la trace. La forme d'une trace est la combinaison unique du nom de l'entité de la portée racine et du nom de la portée. Il s’agit d’un moyen simple de séparer la trace en utilisant le point d’entrée de la requête.

Une fois la forme déterminée, l'échantillonneur prend la décision de conserver ou de rejeter la trace en fonction de son pourcentage d'échantillonnage cible. Si c'est 100%, la trace est automatiquement conservée. Si la valeur est inférieure, la probabilité que l'échantillonneur conserve une trace donnée est déterminée par le pourcentage cible. Par exemple, le pourcentage cible par défaut est de 1 pour une trace aléatoire, donc 1 % de ces traces sont conservées. Si vous préférez, vous pouvez modifier le pourcentage du filtre aléatoire.

Étant donné que l'observateur de trace utilise des pourcentages de débit, le nombre de traces sélectionnées variera en fonction de ce débit.

Pas d'échantillonnage

Certains de nos outils n'utilisent pas d'échantillonnage. Détails d'échantillonnage pour ces outils :

monitoring des navigateurs traçant distribués et monitoring des applications mobiles signalent toutes les étendues.

Nos agents linguistiques sont souvent utilisés en conjonction avec et , et nos agents linguistiques utilisent l'échantillonnage. Cela signifie qu'il y aura probablement beaucoup plus de portées de navigateur et d'applications mobiles que de portées backend, ce qui peut entraîner une déconnexion des portées de navigateur et d'applications mobiles des portées backend . Pour obtenir des conseils sur l'interrogation des traces contenant des étendues frontales et backend, consultez Rechercher les données d'étendue du navigateur.

limites de trace

Notre système de traitement des données inclut des limites internes pour protéger notre infrastructure contre les surtensions inattendues de données : API de trace, spans d'agent, spans de navigateur, spans mobiles et spans lambda. Cette couche protectrice maintient non seulement l’intégrité de notre plateforme, mais garantit également une expérience fiable et cohérente pour tous nos clients. Nous ajustons ces limites selon les besoins en fonction de diverses conditions, mais elles sont fixées avec une approche prospective. À mesure que nos utilisateurs et nos données augmentent, nous étendons la capacité de notre infrastructure et augmentons ces limites. Cet engagement garantit que nous capturons toutes les données clients qui nous sont envoyées et vous offrons une vue claire et ininterrompue de vos données de trace. Pour vérifier si vous atteignez ces limites, vous pouvez vous référer à l' UIdes limites.

Comment les données de trace sont structurées

Comprendre la structure d'une tracedistribuée peut vous aider à :

Comprendre comment les traces sont affichées dans notre UI
Vous aide à interroger les données trace

Une traces distribuée a une structure arborescente, avec des « span enfant » qui font référence à un « span parent ». Ce diagramme montre certaines relations d'étendue importantes dans une trace :

New Relic distributed tracing trace structure diagram

Ce diagramme montre comment les étendues distribuées d'une tracesont liées les unes aux autres.

Ce diagramme montre plusieurs concepts importants :

Trace root. Le premier service ou processus d’une trace est appelé service ou processus root .
Process boundaries. Un processus représente l’exécution d’un morceau de code logique. Des exemples de processus incluent un service backend ou une fonction Lambda. Les intervalles au sein d'un processus sont classés comme suit :
- Entry span:la première travée d'un processus.
- Exit span:un span est considéré comme un span de sortie s'il a) est le parent d'un span d'entrée, ou b) a l'attribut http. ou db. et représente donc un appel externe.
- In-process span: une étendue qui représente un appel de méthode ou une fonction interne et qui n'est pas une étendue de sortie ou d'entrée.
Client spans. Un client span représente un appel vers une autre entité ou dépendance externe. Actuellement, il existe deux types de clients SPAN :
- Datastore. Si un client span possède un attribut préfixé par db. (comme db.statement), il est classé comme un span datastore .
- External. Si un client span a un attribut préfixé par http. (comme http.url) ou a un span enfant dans un autre processus, il est classé comme un span externe. Il s'agit d'une catégorie générale pour tous les appels externes qui ne sont pas des requêtes datastore . Si une étendue externe contient http.url ou net.peer.name, elle est indexée sur la page Services externes .
Trace durationLa durée totale d'une trace est déterminée par la durée écoulée entre le début de la première période et la fin de la dernière période.

Vous pouvez interroger les données de relation d'étendue avec l' explorateur NerdGraph GraphiQL sur api.newrelic.com/graphiql.

Comment les données de trace sont stockées

Comprendre comment nous stockons les données trace peut vous aider à interroger vos données trace .

Nous sauvegardons les données de trace comme :

Span:Un span représente les opérations qui font partie d'une tracedistribuée. Les opérations qu'un span peut représenter incluent l'interaction côté navigateur, la requête de datastore, les appels à d'autres services, la synchronisation au niveau de la méthode et la fonction Lambda. Un exemple : dans un service HTTP, un span est créé au début d'une requête HTTP et terminé lorsque le serveur HTTP renvoie une réponse. L'attribut Span contient des informations importantes sur cette opération (telles que la durée, les données de l'hôte, etc.), y compris les détails de la relation trace (tels que traceId, GUID). Pour les données relatives à l'envergure, voir l'attribut span.
Transaction: Si une entité dans une trace est monitorée par un agent, une requête adressée à cette entité génère un seul événement Transaction. Les transactions permettent de lier les données trace à d'autres fonctionnalités de New Relic. Pour les données relatives aux transactions, voir l'attribut transaction.
Contextuel modifié. Nous stockons des métadonnées qui montrent les calculs sur une trace et les relations entre ses étendues. Pour interroger ces données, utilisez l' explorateur NerdGraph GraphiQL.

Comment le contexte de trace est transmis entre les applications

Nous prenons en charge la norme W3C Trace Context, qui facilite le trace des transactions sur les réseaux et les services. Lorsque vous activez le tracing distribué, les agents New Relic ajoutent des en-têtes HTTP aux requests sortantes d'un service. Les en-têtes HTTP agissent comme des passeports lors d'un voyage international : ils identifient la trace de votre logiciel et transportent des informations importantes lorsqu'ils circulent à travers différents réseaux, processus et systèmes de sécurité.

Les en-têtes contiennent également des informations qui nous aident à relier les étendues entre elles ultérieurement : des métadonnées telles que l'ID de trace, l'ID d'étendue, l'ID de compte New Relic et les informations d'échantillonnage. Consultez le tableau ci-dessous pour plus de détails sur l'en-tête :

Article	Description
`accountId`	Il s'agit de votre identifiant de compte New Relic. Cependant, seuls les membres de votre compte et les administrateurs de New Relic peuvent associer cet identifiant aux informations de votre compte de quelque manière que ce soit.
`appId`	Il s'agit de l'identifiant d'application de l'application générant l'en-tête de la trace. Tout comme `accountId`, cet identifiant ne fournira aucune information à moins que vous ne soyez un utilisateur du compte.
`guid`	Avec le tracing distribué, chaque segment de travail dans une trace est représenté par un `span` et chaque étendue a un attribut `guid` . Le `guid` de la dernière étendue du processus est envoyé avec la requête sortante afin que le premier segment de travail dans le service de réception puisse ajouter ce `guid` comme attribut `parentId` qui connecte les données dans la trace.
Type de parent	La source de l'en-tête de la trace, comme dans mobile, navigateur, application Ruby, etc. Cela devient l’attribut `parent.type` sur la transaction déclenchée par la demande à laquelle cet en-tête est attaché.
Priorité	Une valeur de classement de priorité générée aléatoirement qui permet de déterminer quelles données sont échantillonnées lorsque les limites d'échantillonnage sont atteintes. Il s'agit d'une valeur flottante définie par le premier agent New Relic qui fait partie de la demande, de sorte que toutes les données de la trace auront la même valeur de priorité.
Échantillonné	Une valeur booléenne qui indique à l'agent si des données de trace doivent être collectées pour la demande. Ceci est également ajouté en tant qu'attribut à toutes les données de transaction et de portée collectées.
horodatage	Horodatage Unix en millisecondes lorsque la charge a été créée.
`traceId`	L' ID unique (une chaîne générée aléatoirement) utilisé pour identifier une demande unique lorsqu'elle franchit les limites inter et intra processus. Cet identifiant permet de lier des spans dans une tracedistribuée. Ceci est également ajouté en tant qu'attribut aux données de portée et de transaction.
`transactionId`	L' identifiant unique de l'événement de transaction.
Clé de compte de confiance	Il s’agit d’une clé qui permet d’identifier tous les autres comptes associés à votre compte. Ainsi, si vous avez plusieurs sous-comptes que la trace traverse, nous pouvons confirmer que toutes les données incluses dans la trace proviennent d'une source fiable et nous indiquer quel utilisateur doit avoir accès aux données.
Version et clé de données	Cela identifie les versions majeures/mineures, donc si un agent reçoit un en-tête de trace d'une version avec des modifications radicales par rapport à celle sur laquelle il se trouve, il peut rejeter cet en-tête et signaler le rejet et la raison.

Ces informations d'en-tête sont transmises tout au long de chaque segment d'une trace, à moins que la progression ne soit arrêtée par quelque chose comme un middleware ou des agents qui ne reconnaissent pas le format d'en-tête (voir Figure 1).

Diagram of a failed trace with proprietary headers.

Figure 1

Pour résoudre le problème de propagation des en-têtes, nous prenons en charge la spécification W3C Trace Context qui nécessite deux en-têtes standardisés. Nos derniers agents W3C New Relic envoient et reçoivent ces deux en-têtes obligatoires et, par défaut, ils envoient et reçoivent également l'en-tête de l'agent New Relic précédent :

W3C (traceparent) : l'en-tête principal qui identifie l'intégralité de la trace (ID de trace) et le service appelant (ID d'étendue).
W3C (tracestate) : un en-tête obligatoire qui contient des informations spécifiques au fournisseur et suit l'emplacement d'une trace.
New Relic (newrelic) : l'en-tête propriétaire d'origine qui est toujours envoyé pour maintenir la compatibilité descendante avec les agents New Relic antérieurs.

Cette combinaison de trois en-têtes permet de propager la trace à travers les services instrumentés avec ces types d'agents :

Agents W3C New Relic
Agents New Relic non-W3C
Agents compatibles avec W3C Trace Context