Afficher les dépendances de l'application - Application Real-Time Monitoring Service

Une fois l'agent installé pour votre application, ARMS commence à la surveiller. Sur la page Dependencies, vous pouvez consulter les dépendances de l'application, notamment les appels externes, les appels de base de données et les files d'attente de messages.

Prérequis

Important

ARMS Application Monitoring propose une nouvelle page de détails de surveillance pour les utilisateurs ayant activé le nouveau modèle de facturation. Pour plus d'informations sur ce nouveau modèle, consultez la rubrique Product Billing (New).

Si vous n'avez pas activé le nouveau modèle de facturation mais souhaitez accéder à la nouvelle page de détails de surveillance, cliquez sur Switch to New Version dans la page Application List.

Vous avez installé une sonde pour votre application. Pour obtenir des instructions, consultez la rubrique Overview of Application Monitoring Integration.

Dépendances de l'application

Connectez-vous à la console ARMS. Dans le volet de navigation de gauche, sélectionnez Application Monitoring > Application List.
Dans la page Application List, sélectionnez la région dans la barre de navigation supérieure, puis cliquez sur le nom de l'application.
Remarque
Les icônes de la colonne Language ont les significations suivantes :
- : une application Java connectée à Application Monitoring.
- : une application Golang connectée à Application Monitoring.
- : une application Python connectée à Application Monitoring.
- - : une application connectée à Managed Service for OpenTelemetry.
Dans la barre de navigation supérieure, cliquez sur Dependencies.
- Dans la zone de filtre rapide, vous pouvez filtrer les graphiques et la liste des services par Request Type, Interface Name et Host.
- La zone du graphique de tendance affiche les courbes chronologiques du nombre total de requêtes, du nombre d'erreurs et du temps de réponse moyen pour les appels aux dépendances de l'application dans la plage de temps sélectionnée.
  
  Cliquez sur l'icône pour afficher les statistiques de métriques pour une période spécifique ou comparer les statistiques entre différentes dates. Cliquez sur l'icône pour basculer entre un graphique en barres et un graphique de tendance.
- Dans la zone de liste des services, vous pouvez consulter des informations telles que le nom de l'interface, le type et les métriques RED (nombre de requêtes, nombre d'erreurs et temps de réponse moyen).
  
  Dans la liste des services, vous pouvez effectuer les opérations suivantes :
  - Cliquez sur un nom d'interface, ou sur Details, SQL Analysis ou Exception Analysis dans la colonne Actions pour afficher les détails du service correspondant. Pour plus d'informations, consultez la section Détails des dépendances.
  - Cliquez sur Trace dans la colonne Actions pour afficher la trace correspondante. Pour plus d'informations, consultez la rubrique Trace Explorer.

Frameworks pris en charge

Détails des dépendances

Appels externes

Vue d'ensemble

Dans l'onglet Overview, vous pouvez consulter les statistiques relatives au nombre de requêtes, au nombre d'erreurs et au temps de réponse moyen pour l'adresse de destination ou le service, ainsi qu'une courbe chronologique des appels lents.

Trace Explorer

La fonctionnalité Trace Explorer analyse les données de trace stockées en temps réel, ce qui vous permet de combiner des conditions de filtre et des dimensions d'agrégation pour répondre à divers besoins de diagnostic personnalisés. Pour plus d'informations, consultez la rubrique Trace Explorer.

Publication de messages

Remarque

L'affichage des données de publication de messages n'est pas pris en charge pour les applications Python.

Vue d'ensemble

Dans l'onglet Overview, vous pouvez consulter les statistiques relatives au nombre de requêtes, au nombre d'erreurs et au temps de réponse moyen pour le message cible, ainsi qu'une courbe chronologique des appels lents.

Statistiques d'envoi

L'onglet Sending Statistics répertorie les statistiques d'envoi des topics du point de vue de l'expéditeur, y compris le nombre de requêtes, le nombre d'erreurs et le temps de réponse.

Trace Explorer

Appels de base de données

Remarque

L'affichage des données d'appel de base de données n'est pas pris en charge pour les applications Python.

Vue d'ensemble

Dans l'onglet Overview, vous pouvez consulter les statistiques, les graphiques chronologiques et les distributions relatifs au nombre de requêtes, au nombre d'erreurs et au temps de réponse moyen des appels vers l'instance de base de données cible, ainsi que la distribution du nombre d'appels lents.

Analyse SQL

Dans l'onglet SQL Analysis, vous pouvez identifier les tendances des requêtes (nombre de requêtes, nombre de requêtes SQL lentes et temps de réponse moyen) pour l'instance de base de données sélectionnée, ainsi que les métriques statistiques au niveau des appels SQL. Ces informations vous aident à déterminer quelles instructions SQL provoquent des lenteurs dans les réponses du service.

Remarque

La métrique Return Size est prise en charge uniquement pour les versions MySQL 5.x et nécessite la version 2.7.1.3 ou ultérieure de l'agent Application Monitoring.

Cliquez sur Trace à droite d'une instruction SQL pour afficher la trace complète incluant l'exécution SQL. Pour plus d'informations, consultez la rubrique Trace Explorer.

Analyse des exceptions

Dans l'onglet Exception Analysis, vous pouvez consulter le nombre d'occurrences de chaque exception lors des appels vers la base de données cible dans une plage de temps spécifiée, ainsi que les détails des exceptions. Pour plus d'informations, consultez la rubrique Exception Analysis.

Source de l'appel

Dans l'onglet Call Source, vous pouvez afficher les courbes chronologiques du temps de réponse, du nombre de requêtes et du nombre d'erreurs des interfaces sources qui appellent la base de données cible.

Trace Explorer

FAQ

Base de données

Absence de données pour les appels de base de données

Raisons possibles :

La base de données ne figure pas dans la liste des bases de données prises en charge par ARMS. Pour consulter la liste des bases de données prises en charge, reportez-vous à la rubrique Composants et frameworks Java pris en charge pour ARMS Application Monitoring.
Les versions d'agent antérieures à la 4.x ne prennent pas en charge les bases de données appelées de manière asynchrone ou sans point d'entrée.

Écart dans les appels de base de données lents

ARMS effectue la surveillance depuis le côté client, ce qui signifie que ses mesures couvrent l'intégralité du processus : l'application initie une requête, celle-ci transite par le réseau, le serveur la traite et la réponse revient au client. Par conséquent, les métriques de base de données collectées par ARMS sont influencées par des facteurs tels que le garbage collection (GC) et la latence réseau, ce qui peut entraîner des valeurs plus élevées que celles rapportées directement par le serveur. De plus, ARMS identifie les appels lents en fonction du Slow SQL Threshold configuré dans la page Custom Configuration. Ce seuil est défini par défaut à 500 ms et peut différer de la configuration du serveur de base de données.

Écart dans le volume d'appels de base de données

Une seule base de données peut être accessible par plusieurs applications. La console ARMS affiche uniquement le volume d'appels provenant de l'application actuelle.

Appels externes non enregistrés

Pour l'agent 3.x, les raisons possibles incluent :

Appels externes sans point d'entrée.

Par défaut, l'agent 3.x collecte uniquement les appels externes qui se produisent dans le flux de traitement des interfaces HTTP, des interfaces RPC, des tâches planifiées et de la consommation de messages. Les appels externes, tels que l'accès à la base de données ou les requêtes HTTP, initiés par des pools de threads en arrière-plan ne sont pas collectés.
Appels externes avec un point d'entrée mais avec un changement de thread pendant l'exécution.

L'agent 3.x ne prend pas en charge la propagation automatique des contextes asynchrones. Si un changement de thread se produit, le contexte de trace est perdu et l'appel n'est pas collecté.

Ces deux problèmes peuvent être résolus en mettant à niveau l'agent vers la version 4.x.

Données indéfinies dans les appels externes

Les versions 3.1.x et antérieures de l'agent présentent un défaut dans l'instrumentation Dubbo qui empêche l'agent d'obtenir l'adresse IP du pair. Ce problème a été corrigé dans la version 3.2.x.

Clés illisibles dans les appels Redis

Un problème d'instrumentation dans le framework Lettuce entraîne une récupération incorrecte de la clé. Vous pouvez ignorer la partie illisible de la clé ; le reste de la clé est valide.

Absence de données de trace pour les instructions SQL

Cause : Pour éviter le coût et la surcharge de performance liés au signalement de grandes quantités de données dans des scénarios extrêmes, l'agent ARMS active la compression de span par défaut. Lorsque plusieurs spans enfants sous une span parent partagent le même nom, elles sont compressées en une seule span représentative. Ses attributs stockent alors le nombre, la durée totale, la durée maximale et la durée minimale de toutes les spans enfants identiques. Cependant, cette compression supprime les détails individuels des spans agrégées. Par conséquent, les instructions SQL contenues dans ces spans compressées ne peuvent pas être interrogées directement sur la page Trace Explorer.

Solution : Désactivez la compression de trace.

Remarque

Après avoir désactivé la compression, si une interface d'application accède fréquemment à des composants tels que des bases de données ou Redis, la quantité de données signalées augmentera et la logique d'échantillonnage d'ARMS pour les erreurs et les appels lents sera moins efficace.

Publication de messages

Différence de données entre les vues client et serveur

Les pages Message Subscription et Message Publishing affichent les métriques de performance côté client pour l'application sélectionnée agissant en tant que consommateur ou producteur, tandis que le tableau de bord de surveillance d'une instance MQ affiche les métriques de performance liées aux topics côté serveur.

Formats de nom de span pour les messages

Type de message

Versions d'agent antérieures à la 4.x

Agent 4.x et versions ultérieures

Envoi de message RocketMQ/Ons

Aucune span n'est créée. Seules les piles de méthodes sont enregistrées.

${topic} + publish

Réception de message RocketMQ/Ons

Recv Topic@${topic}

Envoi de message Kafka

Aucune span n'est créée. Seules les piles de méthodes sont enregistrées.

${topic} + publish

Réception de message Kafka

Kafka/topic=${topic}

Envoi de message RabbitMQ

Aucune span n'est créée. Seules les piles de méthodes sont enregistrées.

${exchange} + publish

Réception de message RabbitMQ

Recv Exchange@${exchange}

Prise en charge de Spring Cloud Alibaba RocketMQ

Ce framework est pris en charge dans les versions 4.x et ultérieures de l'agent. Si votre version d'agent est antérieure à la 4.x, mettez à niveau l'agent ARMS.

Métrique Message Delay

Le délai de message correspond au temps total écoulé entre la production et la consommation du message. L'unité de cette métrique est la milliseconde (ms). Cette métrique est actuellement collectée uniquement pour RocketMQ Client et Ons Client.

Absence de traces ou de métriques du consommateur

Cela peut se produire si la version de l'agent est antérieure à la 4.x et que vous utilisez des expressions lambda pour définir la logique de consommation dans l'écouteur de messages.

Étant donné que l'amélioration des classes pour les expressions lambda échoue dans les versions 2.x et 3.x de l'agent, vous pouvez mettre à niveau l'agent vers la version 4.x pour résoudre ce problème.

Erreur d'en-tête « Magic v1 » Kafka

L'agent Java utilise le champ Header des messages Kafka pour propager le contexte de trace. Dans les versions de Kafka antérieures à la 0.11.0.0 (pour les clients et les brokers), le format de message ne prend pas en charge les en-têtes. Si vous utilisez une ancienne version de Kafka pour votre broker ou votre client, migrez vers la version 0.11.0.0 ou ultérieure. Si vous ne pouvez pas migrer immédiatement, pour les versions de l'agent Java antérieures à la 4.x, vous pouvez désactiver l'amélioration du composant Kafka (commutateur kafka-plugin) dans la section Agent Switch Settings de la page Custom Configurations de l'application. Pour les versions 4.x et ultérieures de l'agent Java, ajoutez le paramètre JVM -Dotel.instrumentation.kafka.producer-propagation.enabled=false lors du démarrage du service comme solution de contournement.

Absence de spans de message dans les traces

Vérifiez si les SDK clients de file d'attente de messages utilisés par vos applications producteur et consommateur sont pris en charge par ARMS. Pour consulter les composants pris en charge, reportez-vous à la rubrique Composants et frameworks Java pris en charge pour ARMS Application Monitoring.
Vérifiez si vos applications producteur et consommateur sont connectées à Application Monitoring ou à Managed Service for OpenTelemetry, si leurs commutateurs d'agent et de plugin sont activés et si elles signalent les données dans la même région. Les spans pour l'envoi de messages sont générées dans le producteur, et les spans pour la réception de messages sont générées dans le consommateur. Si l'une des applications n'est pas correctement configurée, ses spans seront manquantes.
Si vous ne voyez pas les spans pour l'envoi de messages, vérifiez si la version de l'agent de l'application producteur est la 4.x ou ultérieure. Dans les versions d'agent antérieures à la 4.x, l'envoi d'un message n'est pas enregistré en tant que span distincte, mais est inclus dans la pile de méthodes de la span parent. Vous pouvez cliquer sur l'icône à côté de la span parent pour afficher la pile d'appels de méthode.
Si vous ne voyez pas les spans pour la réception de messages, vérifiez si vous avez configuré un Invalid API Filter dans la section Interface Call Configuration de la page Custom Configurations de l'application consommateur. Ce filtre sert à exclure la collecte de spans indésirables.

Différence de temps de réponse Kafka selon les versions d'agent

Symptôme : Le temps de réponse chute de plusieurs secondes à 0,x milliseconde.

Cause :

Dans les versions 3.x et antérieures de l'agent, lors du traitement d'un BatchMessageListener, un lot de messages est traité comme un seul appel et leurs durées sont agrégées en une seule valeur.

Les versions 4.x et ultérieures de l'agent séparent cette logique, en comptant chaque message comme un appel individuel. Par conséquent, après la mise à niveau d'un agent 3.x vers un agent 4.x, le temps de réponse par appel diminuera considérablement tandis que le nombre d'appels augmentera significativement.

La méthode statistique utilisée dans la version 3.x était moins précise et a été améliorée dans la version 4.x.