Application Real-Time Monitoring Service:Services fournis

Que signifie la trace amont pour un appel d'API ?

Cette notion indique le nombre de fois où les applications en amont appellent l'application concernée. Les enregistrements n'apparaissent que si une sonde ARMS est installée sur l'application en amont. En l'absence de sonde, aucun enregistrement n'est généré. Les auto-appels de l'application sont également considérés comme des appels entrants.

Absence de point de terminaison d'ingestion amont pour certaines API

Si une interface reçoit réellement des appels en amont mais que les applications sources ne disposent pas de sondes ARMS, ces appels n'apparaîtront pas dans les traces.

Inversion des liens amont et aval

Lorsque votre trace utilise des composants SkyWalking, l'intégralité de la trace adopte par défaut le protocole SkyWalking. Avant la version 4.2.x, ARMS rencontrait des difficultés à prendre en charge ce protocole, ce qui entraînait des échecs d'identification des relations amont/aval. Pour résoudre ce problème, effectuez une mise à niveau vers la version 4.2.x ou ultérieure. Vous pouvez également forcer l'utilisation d'un protocole autre que SkyWalking pour la propagation du contexte de trace via la page Custom Configuration, sous la section Trace Context Propagation Protocol Settings. Pour plus d'instructions, consultez Paramètres du protocole de propagation du contexte de trace.

Le compteur d'erreurs de l'interface Dubbo n'est pas nul, mais aucune trace n'est trouvée

Dans les versions de sonde antérieures à la 3,2.x, les traces Dubbo n'enregistraient pas correctement les codes d'état, empêchant l'affichage des traces d'erreur. Ce problème a été corrigé à partir de la version 3.2.x.

Le compteur d'exceptions n'est pas nul lors des appels d'API, mais aucune trace d'exception n'apparaît dans la recherche de traces

Avant la version 4.1.x, les sondes n'enregistraient que les traces d'erreur et les traces lentes. Par conséquent, les exceptions ne générant ni erreur ni lenteur pouvaient ne pas être échantillonnées. À partir de la version 4.1.x, les sondes échantillonnent également les traces d'exception, ce qui permet leur détection.

Pourquoi le trafic de l'interface a-t-il chuté ?

Commencez par vérifier si le trafic a effectivement diminué en examinant l'utilisation du CPU, les E/S réseau et d'autres métriques autour du moment de la baisse :

• Si c'est le cas, il s'agit généralement d'une baisse réelle du trafic.

• Sinon, un problème côté serveur ARMS est possible. Dans ce cas, soumettez un ticket pour obtenir de l'aide.

Le trafic de surveillance Spring Cloud Gateway est imprécis

Les versions de sonde antérieures à la 4.x présentaient des bugs dans l'instrumentation de Spring Cloud Gateway, entraînant une perte de trafic dans certains scénarios. Mettez à niveau vers la version 4.x ou ultérieure de la sonde.

Puis-je afficher les instructions SQL lentes pour une interface ?

Que signifient les points jaunes devant les interfaces dans l'ancienne console ?

Survolez un point avec la souris pour voir sa signification.

• Un point jaune indique un appel lent. Par défaut, les requêtes prenant plus de 500 ms sont marquées comme lentes. Vous pouvez ajuster ce seuil dans la section Interface Call Configuration de la page Custom Configuration.

• Un point rouge indique une erreur.

Pourquoi certains codes d'état 5xx ne sont-ils pas collectés ?

Conformément à la norme RFC7231, des codes d'état tels que 502 et 504 sont générés par les passerelles et ne reflètent pas nécessairement la réponse réelle du service appelé. Si la passerelle ne dispose pas de la surveillance ARMS alors que le service backend en est équipé, ces réponses 5xx ne seront pas comptabilisées.

Qu'est-ce que NetWork And Dubbo Response Decode ?

Il s'agit d'un span qui mesure le temps consacré à la désérialisation des données de la couche de transport Dubbo.

Pourquoi les noms d'interface contiennent-ils * ou des mots-clés ARMS ?

Cela se produit lorsque les noms d'interface sont très variables. ARMS regroupe les interfaces similaires en remplaçant les parties divergentes. Pour plus de détails, consultez Mécanisme de convergence ARMS.

Pourquoi la durée de l'appel externe diffère-t-elle de la durée réelle du service aval ?

La durée côté serveur mesure uniquement le temps de traitement de la requête par l'interface. La durée côté client inclut l'établissement de la connexion et le temps réseau. La console ARMS affiche ces deux durées séparément, mais le temps lié au réseau ne peut pas être déterminé avec précision.

L'interface renvoie une réponse normale, mais le compteur d'exceptions pour un seul appel n'est pas nul

Ce comportement est attendu. Certains frameworks (comme OkHttp3) lèvent des exceptions internes qui sont interceptées en externe, de sorte que la logique métier reste normale. Comme ARMS instrumente ces frameworks, il enregistre ces exceptions, bien qu'elles n'indiquent pas de problèmes métier réels. Vous pouvez décider s'il convient de les traiter. Ces statistiques ignorent les détails des messages d'exception. Pour voir le message d'exception réel, cliquez sur une trace pour l'exception, puis cliquez sur l'icône à côté de l'interface pour afficher l'exception dans la pile des méthodes.

Noms d'interface HTTP tels que /error, /404, /*, /

Ces noms résultent généralement de requêtes inattendues qu'ARMS ne peut pas associer à une route. Les causes courantes incluent :

• Requête vers une URL inexistante.

• En-têtes de requête invalides provoquant des échecs de validation, par exemple des en-têtes contenant des caractères non valides.

• Utilisation de serveurs HTTP sans mécanisme de routage, tels que Netty brut.

Pourquoi les comptes de requêtes dans les appels d'interface diffèrent-ils de ceux de l'analyse des traces ?

L'analyse des traces repose sur les données de trace et est affectée par le taux d'échantillonnage.

Pourquoi les temps de réponse quantiles diffèrent-ils entre les détails de l'interface et l'analyse des traces ?

Les détails de l'interface calculent les quantiles par instance à l'aide d'algorithmes de regroupement. L'analyse des traces calcule les quantiles à partir des spans échantillonnés pour l'interface. Par conséquent, les valeurs diffèrent. Pour plus de détails, consultez Principes de calcul des métriques quantiles ARMS.

Le volume d'appels d'API a approximativement doublé

Cela se produit généralement si les sondes 3.x et 4.x ont été accidentellement attachées toutes les deux lors d'une mise à niveau. Accédez à Application Configuration > Agent Management, sélectionnez n'importe quelle sonde et cliquez sur View Details pour vérifier les paramètres JVM.

La présence de deux paramètres -javaagent indique que les sondes 3.x et 4.x sont toutes deux attachées.

Par exemple, la sonde 3.x utilise -javaagent:/home/admin/.opt/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar

Versions d'agent antérieures à 4.x

Agent 4.x et versions ultérieures

Envoi de message RocketMQ/Ons

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

${topic} + publish

Réception de message RocketMQ/Ons

Recv Topic@${topic}

Recv Topic@${topic}

Envoi de message Kafka

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

${topic} + publish

Réception de message Kafka

Kafka/topic=${topic}

Kafka/topic=${topic}

Envoi de message RabbitMQ

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

${exchange} + publish

Réception de message RabbitMQ

Recv Exchange@${exchange}

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 à 4.x, mettez à niveau l'agent ARMS.

Métrique de délai des messages

Le délai des messages 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 de consommateur

Cela peut se produire si la version de l'agent est antérieure à 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 à 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 à 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 au démarrage du service comme solution de contournement.

Absence de spans de message dans les traces

1. Vérifiez si les SDK clients de file d'attente de messages utilisés par vos applications productrices et consommatrices sont pris en charge par ARMS. Pour connaître les composants pris en charge, consultez Composants et frameworks Java pris en charge pour la surveillance des applications ARMS.

2. Vérifiez si vos applications productrices et consommatrices sont connectées à Application Monitoring ou à Managed Service for OpenTelemetry, si les commutateurs de l'agent et des plugins sont activés et si elles rapportent dans la même région. Les spans pour l'envoi de messages sont générés dans le producteur, et les spans pour la réception de messages sont générés dans le consommateur. Si l'une des applications n'est pas configurée correctement, ses spans seront manquants.

3. Si vous ne voyez pas les spans pour l'envoi de messages, vérifiez si la version de l'agent de l'application productrice est 4.x ou ultérieure. Dans les versions antérieures à 4.x, l'envoi d'un message n'est pas enregistré comme un span distinct, mais est inclus dans la pile de méthodes du span parent. Vous pouvez cliquer sur l'icône à côté du span parent pour afficher la pile d'appels de méthode.

4. Si vous ne voyez pas les spans pour la réception de messages, vérifiez si vous avez configuré un filtre Invalid API Filter dans la section Interface Call Configuration de la page Custom Configurations de l'application consommatrice. Ce filtre sert à exclure la collecte de spans indésirables.

Différence de temps de réponse Kafka selon les versions de l'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.

Dans les abonnements aux messages, pourquoi la consommation Kafka apparaît-elle en double dans les traces ?

Si vous utilisez batchMessageListener de spring-kafka, chaque message du lot est enregistré dans la même logique de consommation Kafka. spring-kafka implémente batchMessageListener de ces manières :

• Ajoutez l'annotation @KafkaListener(topics = "my-topic", batch = true) à votre méthode de consommation.

• Implémentez l'interface BatchMessageListener dans la classe de votre méthode de consommation.

• Activez le mode de consommation par lot dans les propriétés du conteneur Kafka Message Listener : containerProperties.setBatchListener(true).

Pourquoi le filtrage des interfaces invalides ne fonctionne-t-il pas pour les interfaces de tâches planifiées ?

Vérifiez la version de votre sonde. Pour les sondes inférieures à 3.2.0 ou comprises entre 4.0.0 et 4.2.0, le filtrage des interfaces invalides peut ne pas prendre effet. Nous recommandons de mettre à niveau vers la version de sonde 3.2.10 ou supérieure à 4.2.0.

Pourquoi les appels externes sont-ils absents des traces alors qu'ils existent dans les tâches planifiées ?

Étapes de dépannage :

• Si les traces des tâches planifiées elles-mêmes sont manquantes, vérifiez d'abord Composants et frameworks Java pris en charge pour la surveillance des applications ARMS et vérifiez Paramètres des commutateurs de sonde.

• Si seuls les appels externes sont manquants et que votre version de sonde est inférieure à 4.0.0, la propagation du contexte de trace peut échouer dans les scénarios asynchrones. Mettez à niveau vers la version de sonde 4.0.0 ou ultérieure, ou utilisez la fonctionnalité Paramètres avancés pour configurer la propagation automatique du contexte.

Pourquoi les données du framework xxl-job sont-elles manquantes ?

• Les sondes de version inférieure à 3.1.0 ne prennent pas en charge xxl-job. Mettez à niveau vers une version de sonde plus récente.

• Si vous avez personnalisé le code xxl-job, par exemple en renommant des classes clés (y compris les noms de classe et de package), l'instrumentation de la sonde ne fonctionnera pas. Dans ce cas, ajoutez une instrumentation personnalisée aux traces à l'aide du SDK Java OpenTelemetry.