Données de trace manquantes

Pour que le tracing distribué signale les détails de tous les nœuds d'une trace, chaque application doit être monitorée par un agent New Relic sur lequel le tracing distribué est activé.

Si le tracing distribué n'est pas activé sur le compte New Relic d'une application, les problèmes suivants se produiront :

• Sa page d' UI de tracing distribué n'aura pas de données.
• Il ne signalera pas de données aux traces distribuées d'autres comptes.

Lorsque vous activez le tracing distribué pour les applications et les services que New Relic instrumente automatiquement, vous verrez généralement des données complètes et détaillées pour ces nœuds dans l'UI de tracing distribué.

Cependant, vous remarquerez peut-être que certains services ou applications sont manquants dans la trace, ou que certaines étendues internes que vous vous attendez à voir sont manquantes. Si tel est le cas, vous souhaiterez peut-être implémenter instrumentation personnalisée des applications ou des transactions spécifiques pour voir plus de détails dans la trace. Voici quelques exemples de situations dans lesquelles vous pourriez avoir besoin de procéder ainsi :

• Transactions not automatically instrumentedPour vous assurer que votre application est automatiquement instrumentée, lisez la documentation de compatibilité et des exigences de l'agent New Relic que vous utilisez. Si une application n'est pas automatiquement instrumentée, ou si vous souhaitez ajouter instrumentation d'activité spécifique, consultez instrumentation personnalisée.
• All Go applicationsL'agent Go, contrairement à d'autres agents, nécessite une instrumentation manuelle de votre code. Pour obtenir des instructions, consultez Instrumenter une application Go.
• A service doesn't use HTTPSi un service ne communique pas via HTTP, l'agent New Relic n'enverra pas d'en-têtes de tracing distribué. Cela peut être le cas pour certaines applications non Web ou fichiers d'attente de messages. Pour remédier à cela, utilisez les API de tracing distribué pour instrument l’application appelante ou appelée.

Si votre agent APMne peut pas écrire de données suffisamment rapidement dans l'observateur de trace, queue_size est une configuration d'agent APM supplémentaire pour limiter le nombre d'intervalles que l'agent conservera. Consultez les exemples suivants pour votre agent :

<configuration . . . >
   <infiniteTracing>
      <trace_observer>
         <span_events queue_size="100000" />
      </trace_observer>
   </infiniteTracing>
</configuration>

NEW_RELIC_INFINITE_TRACING_SPAN_EVENTS_QUEUE_SIZE=100000

infinite_tracing.span_queue_size = 100000

NEW_RELIC_INFINITE_TRACING_SPAN_QUEUE_SIZE = 100000

Parfois, la propagation de l'en-tête réussit, mais les informations de portée ne sont pas envoyées à New Relic. Par exemple, si OpenTelemetry n’est pas instrumenté avec un exportateur New Relic, les détails de la plage ne parviennent jamais à New Relic.

Dans ce diagramme, notez que la propagation de l'en-tête est réussie, mais aucun exportateur n'est configuré dans le service 2 pour envoyer le span à New Relic :

Le diagramme suivant montre également une propagation d'en-tête réussie, mais il inclut un exportateur dans le service 2 qui envoie les détails de l'étendue à New Relic (voir API Trace) :

Le tracing distribué standard pour APMutilise l'échantillonnage adaptatif. Cela signifie qu'un pourcentage d'appels à un service sera signalé dans le cadre d'une trace distribuée. Il est possible que des appels spécifiques à votre service n'aient pas été sélectionnés pour être échantillonnés.

Il existe des limites quant au nombre de plages pouvant être collectées et affichées. Si une application génère un très grand nombre d'étendues pour un seul appel, elle peut dépasser la limite de collecte d'étendues de l'agent APM pour ce cycle de collecte. Cela pourrait entraîner des pertes de données et limiter considérablement le nombre de traces que l'agent peut entièrement échantillonner et signaler.

Nous n'affichons actuellement que 10 000 spans à la fois.

Les intervalles doivent être envoyés dans les soixante dernières minutes pour être capturés dans un index de trace. Si vous envoyez des données datant de plus de soixante minutes mais de plus d'un jour, les données seront toujours écrites. Cependant, il ne sera pas intégré à l'index trace, qui contrôle la liste trace dans l'UI de tracing distribué. Si une plage a un horodatage plus ancien qu'un jour, elle sera supprimée. Cela se produit souvent lorsqu'il y a un décalage d'horloge (différences de synchronisation) entre les tâches système ou les tâches d'arrière-plan de longue durée.

The span timestamp cannot be older than 60 minutes.

Si vos transactions n'envoient que l'en-tête propriétaire New Relic, certains intergiciels peuvent ne pas reconnaître le format et supprimer les informations comme indiqué dans ce diagramme :

Une solution consiste à mettre à niveau votre agent New Relic vers une version prenant en charge le contexte de trace W3C. Dans le diagramme ci-dessous, l'agent New Relic conforme au W3C transmet l'en-tête précédent ainsi que deux en-têtes standardisés :

Quelques problèmes potentiels avec les proxys et autres intermédiaires :

• Incomplete trace. Certains intermédiaires ne propageront pas automatiquement l' en-tête de tracing distribué. Dans ce cas, vous devez configurer ce composant pour permettre à l’en-tête d’être transmis de la source à la destination. Pour obtenir des instructions, consultez la documentation de ce composant intermédiaire.

• Missing intermediary in trace. Si l'intermédiaire est New Relic-monitorer, assurez-vous qu'il propage l'en-tête newrelic généré ou mis à jour par l'agent New Relic exécuté sur cet intermédiaire. Cela peut se manifester lorsqu'un intermédiaire était auparavant visible dans la trace, mais a disparu après l'activation du tracing distribué pour une entité en amont (par exemple, une application de monitoring de navigateur).

  Conseil

  Si une entité signale des données trace à un autre système de tracing, vous pouvez utiliser l'ID trace de l'UI de New Relic pour rechercher les étendues manquantes dans d'autres systèmes de tracing.

Si chaque agent d'une chaîne prend en charge W3C Trace Context, nous pouvons alors assembler les segments dans une trace complète. Si une partie de la chaîne provient d'un agent, tel que Zipkin, qui ne prend pas en charge W3C Trace Context, les étendues provenant de cet agent peuvent ne pas être incluses dans la trace.

Si une trace contient des données provenant du moniteur d'applications de plusieurs comptes New Relic et que vos autorisations d'utilisateur ne vous permettent pas d'accéder à ces comptes, certains détails de l'étendue et du service seront masqués dans l'UI.

Par exemple, vous pouvez voir une série d'astérisques (*****) au lieu du nom du service dans votre liste de tracing distribué si vous n'avez pas accès au compte lié au service.

La liste trace est générée par des index trace, qui sont capturés dans une fenêtre de vingt minutes à compter de la réception des premières traces.

En général, cela est dû à des retards.

Si vous constatez des temps backend inhabituellement courts pour une trace longue, il s'agit probablement d'un problème lié à l'horodatage envoyé.

Par exemple, la portée racine peut consister à republier des microsecondes sous forme de millisecondes. Cela peut également se produire si la racine est une application de navigateur. Lorsque vous utilisez un client externe comme un navigateur Web, vous risquez de rencontrer plus souvent des décalages d'horloge (différences de synchronisation).

Les anciennes versions de certains agents APMsont incompatibles avec le tracing distribué pour les applications de navigateur. Si l'application de navigateur envoie une requête AJAX à une application APM exécutant un agent incompatible, l'agent APM peut ne pas enregistrer les données de transaction et d'étendue pour cette requête.

Si le tracing distribué est activé pour une application de navigateur et que vous ne voyez pas de données de transaction ou d'étendue pour requests APM en aval, examinez les données de navigateur dans les exigences de tracing distribué et confirmez que toutes les applications exécutent des versions prises en charge de l'agent APM.

Si la trace semble manquer de portées finales d'utilisateur, assurez-vous d'avoir lu et compris les exigences de tracing distribué du navigateur et les procédures d'activation.

Sur la page UI AJAX , il existe des liens vers l'UI de tracing distribué, indépendamment du fait qu'il existe ou non des étendues finales d'utilisateur présentes dans cette trace. Pour plus de détails sur les données qui génèrent des étendues, voir Exigences.

Les anciennes versions de certains agents APMsont incompatibles avec le tracing distribué pour les applications de navigateur. Si les étendues APM manquent systématiquement dans la trace qui inclut les applications de navigateur, veuillez vous référer aux données du navigateur dans le tracing distribué des exigences et confirmer que toutes les applications exécutent des versions prises en charge de l'agent APM.

Pour d'autres causes d'étendues de navigateur orphelines, voir Rapport d'étendueBrowser .

Cause potentielle : pour les applications qui ont plusieurs noms d’application, l’attribut entity.name sera associé uniquement au nom d’application principal. Pour rechercher par d’autres noms d’application, effectuez une recherche à l’aide de l’attribut appName .

Les questions concernant l'intégration avec OpenTelemetry doivent être adressées au Forum d'assistance.