Application Real-Time Monitoring Service:Configuration personnalisée des applications Java

Prérequis

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

Procédure

1. Connectez-vous à la console ARMS. Dans le volet de navigation de gauche, sélectionnez Application Monitoring > Application List.

2. 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.

3. Dans la barre de navigation supérieure, sélectionnez Application Configuration > Custom Configurations.

4. Définissez les paramètres de configuration personnalisée et cliquez sur Save.

Paramètres d'échantillonnage

Dans la section Sampling Settings, vous pouvez configurer les politiques d'échantillonnage, le taux d'échantillonnage et les caractéristiques des interfaces toujours échantillonnées pour les traces. Vous pouvez également activer ou désactiver l'échantillonnage à faible trafic. Pour plus d'informations, consultez la rubrique Select a trace sampling mode (agent V3.2.8 or later).

Paramètres des commutateurs de l'agent

Dans la section Agent Switch Settings, vous pouvez activer ou désactiver la surveillance des applications et basculer les commutateurs individuels de l'agent.

Cette section répertorie tous les commutateurs d'agent disponibles dans une grille. Vous pouvez activer ou désactiver la surveillance pour des frameworks et des fonctionnalités spécifiques selon vos besoins.

Paramètres de profilage des threads

Dans la section Thread profiling settings, vous pouvez activer ou désactiver le commutateur principal du profilage des threads.

Configuration de l'association des journaux d'application

Dans la section Application log association configuration, vous pouvez configurer les informations de source de journal pour injecter automatiquement TraceId et SpanId. Pour plus d'informations, consultez la rubrique Log analysis.

• Automatic TraceId and SpanId injection : lorsqu'elle est activée, cette option permet à l'agent d'injecter automatiquement TraceId et SpanId dans vos journaux sans modifier votre configuration de journalisation.

  Effet :

  # log4j
  2024.04.12 17:14:18 WARN  log4j-11 c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a simple trace log
  17:14:18 WARN [log4j-ThreadPool-11] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a log with exception
  java.lang.RuntimeException: null
  	at com.example.demo2.TraceIdLogWorker.doWork(TraceIdLogWorker.java:49)
  	at org.apache.arms.java.util.concurrent.ExecutorServiceInterceptor.call(ExecutorServiceInterceptor.java:71)
  	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
  
  # log4j2
  17:14 [Thread.ResolverScan-1] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} This is a log with exception
  java.lang.RuntimeException: null
  	at com.example.demo2.TraceIdLogWorker.doWork(TraceIdLogWorker.java:49)
  	at org.apache.arms.arthas.resolver.DefaultArtifactResolverChain$DefaultTask.execute(DefaultArtifactResolverChain.java:115)
  
  # logback
  17:14:18 WARN [logback-ThreadPool-1] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a simple trace log
  17:14:18 WARN [logback-ThreadPool-1] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a log with exception
  java.lang.RuntimeException: null
  	at com.example.demo2.TraceIdLogWorker.doWork(TraceIdLogWorker.java:49)

• Add TraceId to log MDC : par défaut, l'agent V4.x et les versions ultérieures ne prennent pas en charge l'obtention de TraceId à l'aide de org.slf4j.MDC.get("EagleEye-TraceID"). Pour utiliser cette méthode, activez ce commutateur.

Paramètres de convergence d'URL

Dans la section URL Convergence Settings, vous pouvez activer ou désactiver la convergence d'URL et configurer le seuil et les règles de convergence. La convergence d'URL regroupe une série d'URL similaires et les affiche sous la forme d'une seule entrée. Par exemple, elle regroupe les URL commençant par /service/demo/. Le seuil de convergence correspond au nombre minimal d'URL requis pour déclencher la convergence. Par exemple, si le seuil est de 100, un groupe d'URL correspondant à l'expression régulière de la règle n'est convergé qu'après avoir atteint ce nombre. Pour plus d'informations, consultez la rubrique How ARMS convergence works.

Surveillance Arthas

Dans la section Arthas Monitoring, vous pouvez activer ou désactiver la fonctionnalité de diagnostic Arthas et spécifier les adresses IP sur lesquelles elle doit être active. Pour plus d'informations, consultez la rubrique Arthas diagnostics.

Paramètres de profilage continu

Dans la section Continuous profiling settings, vous pouvez activer ou désactiver le commutateur principal ainsi que les fonctionnalités de point chaud CPU, de point chaud mémoire et de point chaud de code. Vous pouvez également spécifier les adresses IP ou les blocs CIDR où le profilage doit être actif. Pour plus d'informations, consultez la rubrique Continuous profiling for Java applications.

Paramètres de masquage des données

Dans la section Data Masking Settings, vous pouvez configurer les règles de désensibilisation. L'agent désensibilise ensuite les données telles que les paramètres système JVM, les fichiers YAML Kubernetes, les paramètres d'entrée de méthode et les variables d'environnement et système Arthas lors de la collecte. Dans les règles de désensibilisation, les éléments sont séparés par des virgules. Chaque élément représente une expression régulière non sensible à la casse. Par exemple, password équivaut à l'expression régulière .password..

Lorsque l'agent collecte des données, il filtre les clés de données par rapport à ces expressions. Si une clé correspond à une règle, l'agent la considère comme sensible et masque sa valeur. Par exemple, si vous définissez la règle sur licenseKey, les informations contenant la clé -Darms.licenseKey sont désensibilisées.

Après avoir activé la désensibilisation des adresses IP, l'agent désensibilise automatiquement les informations impliquant des adresses IP, telles que les adresses d'endpoint sur diverses pages de la console de surveillance des applications. Ce processus n'affecte pas l'affichage des données de surveillance.

Configuration des appels d'API

Dans la section Interface call configuration, vous pouvez configurer des politiques telles que le seuil d'appel lent, les listes d'autorisation d'exceptions, la liste d'autorisation des codes d'état HTTP et le filtrage des appels d'interface invalides.

• Slow call threshold : la valeur par défaut est de 500 ms. Un appel d'interface est marqué comme lent si son temps de réponse dépasse ce seuil.

• HTTP status code whitelist :

  Par défaut, les codes d'état HTTP supérieurs ou égaux à 400 sont classés comme des appels en erreur. Si vous ne souhaitez pas classer certains codes d'état comme des erreurs, vous pouvez les ajouter à la liste d'autorisation.

  Ce paramètre affecte uniquement les frameworks HTTP actuellement pris en charge par la surveillance des applications.

  Données concernées : métriques de comptage des erreurs pour les serveurs et clients HTTP (arms_http_requests_error_count, arms_http_client_requests_error_count et arms_app_requests_error_count) et statut des spans.

  Fonctionnalités concernées : les comptages d'erreurs dans les onglets Overview, Provided Services et Dependencies, ainsi que le statut des spans et les alertes de comptage d'erreurs dans la page Trace Explorer.

  Format : saisissez un seul code d'état. Pour saisir plusieurs codes, séparez-les par des virgules (,). La correspondance floue n'est pas prise en charge.

  Exemple : 403,502

  Valeur par défaut : vide

• Invalid interface call filtering :

  Si vous souhaitez masquer certains appels dans l'onglet Provided Services, vous pouvez saisir les noms des interfaces que vous souhaitez ignorer. L'agent ne signalera pas les données d'observabilité pour ces interfaces, et celles-ci n'apparaîtront pas sur la page des appels d'interface.

  Remarque

  • Pour les agents Java antérieurs à la version V4.2.0, cette fonctionnalité n'est effective que pour les interfaces qui apparaissent dans l'onglet Provided Services.

  • Pour l'agent Java V4.2.0 et les versions ultérieures, cette fonctionnalité est effective pour tout LocalRootSpan.

  Données concernées : toutes les métriques et spans pour les interfaces correspondantes sont ignorées.

  Fonctionnalités concernées : toutes les métriques pour les interfaces correspondantes dans les onglets Overview, Provided Services et Dependencies. Le nombre de spans, le volume d'appels, le comptage des erreurs et les alertes d'appels lents pour les interfaces correspondantes dans la page Trace Explorer sont également concernés.

  Format : utilisez une chaîne ou une expression AntPath pour faire correspondre le nom complet d'une interface invalide. Pour saisir plusieurs règles, séparez-les par des virgules (,). La valeur par défaut est écrite sous forme d'expression AntPath pour assurer la compatibilité avec les données existantes. Il est recommandé de ne pas la supprimer. Ajoutez les nouvelles configurations aux règles existantes.

  Exemple : /api/test/*,/api/playground/create

  Valeur par défaut : /**/*.jpg,/**/*.png,/**/*.js,/**/*.jpeg,/**/*.pdf,/**/*.xlsx,/**/*.txt,/**/*.docs,/**/*.gif,/**/*.csv

• Record upstream interface name in interface call metrics et Record upstream application name in interface call metrics :

  Objectif : contrôle si les métriques d'interface enregistrent l'application amont et l'interface qui ont effectué l'appel. Cela affecte principalement la disponibilité des données pour les services amont et aval. Si une application possède de nombreuses applications amont, l'enregistrement de ces informations peut augmenter considérablement le volume de métriques signalées et entraîner des coûts plus élevés.

  Effet : après avoir désactivé l'enregistrement des applications et interfaces amont pour les métriques d'interface, le comptage de données correspondant tombe à zéro.

• Record original status code in interface call metrics :

  Objectif : enregistre le code de réponse original dans les métriques liées aux interfaces HTTP.

  Effet :

  Une fois cette option activée, vous pouvez afficher le code de réponse original des interfaces HTTP dans les détails des appels d'interface. Cela permet des statistiques et une analyse plus détaillées des codes d'état.

• Record HTTP method name for interface : après avoir activé ce commutateur, le nom d'interface étendu dans la page des appels d'interface inclut la méthode de requête HTTP. Par exemple, le nom passe de /api/v1/use/{userId} à GET /api/v1/use/{userId}.

Configuration des appels de base de données

Dans la section Database call configuration, vous pouvez configurer le seuil SQL lent, la longueur maximale des instructions SQL collectées, spécifier s'il faut afficher les valeurs liées aux variables et les constantes dans les instructions SQL, ainsi que déterminer s'il faut enregistrer la taille des valeurs de retour des requêtes MySQL.

• Display bound variable values in SQL : Capture les valeurs des variables liées aux paramètres PreparedStatement. Cette modification prend effet sans redémarrer l'application.

  L'agent enregistre les valeurs des paramètres PreparedStatement dans les attributs du span d'appel de base de données correspondant. La clé est db.bindvalue et la valeur est une liste de valeurs de variables séparées par des virgules. Cette modification prend effet sans redémarrer l'application.

  • Ce paramètre est pris en charge par tous les frameworks basés sur JDBC actuellement pris en charge par ARMS.

  • Types de variables de base de données pris en charge : Boolean, Byte, Short, Int, Long, Float, Double, BigDecimal et Date.

  • L'activation de ce commutateur entraîne une surcharge supplémentaire proportionnelle au nombre de variables dans l'instruction SQL. Dans les scénarios officiels de test de charge avec une seule variable, l'activation de ce commutateur ajoute moins de 0,5 % de surcharge CPU et une surcharge mémoire négligeable.

  La figure suivante illustre l'effet après l'activation de ce commutateur :

  Une fois activé, vous pouvez consulter l'attribut db.bindvalue et ses valeurs de variables correspondantes dans le panneau Span Details d'un span d'appel de base de données.

• Display constant values in SQL : L'agent tronque uniquement les instructions SQL sans appliquer de traitement supplémentaire. Cette modification prend effet sans redémarrer l'application. Si les instructions SQL ne varient que par leurs valeurs constantes, elles peuvent devenir trop fragmentées et finir par être regroupées sous {ARMS_OTHERS}. Nous vous recommandons de ne pas activer cette option.

• Record original JDBC connection string : Par défaut, l'agent ne peut analyser qu'un nombre limité de formats de chaîne de connexion JDBC. Pour les chaînes de connexion que l'agent ne parvient pas à analyser correctement, il enregistre l'endpoint comme UnknownEndpoint. Si vous activez ce commutateur, l'agent enregistre la chaîne de connexion JDBC originale. Par exemple, une chaîne de connexion jdbc:h2:file précédemment non reconnue et enregistrée comme UnknownEndpoint sera correctement enregistrée après l'activation de ce commutateur.

Paramètres de propagation du contexte de trace

Dans la section Trace Context Propagation Protocol Settings, vous pouvez sélectionner le protocole de propagation du contexte de trace qui répond à vos besoins.

Par défaut, l'agent ARMS sélectionne un protocole de propagation du contexte de trace en fonction de la présence d'en-têtes de protocole spécifiques dans les en-têtes d'une requête. Pour plus d'informations, consultez la politique de sélection du protocole de propagation du contexte de trace ARMS.

Sur cette page, vous pouvez définir n'importe quel protocole comme protocole prioritaire. Après avoir sélectionné et enregistré la configuration, ARMS donne la priorité à la détection des en-têtes de requête définis par ce protocole. Par exemple, avec la configuration suivante, l'agent détecte les contextes de protocole dans l'ordre suivant pour les appels entrants : Jaeger, EagleEye, W3C, SkyWalking et Zipkin.

Vous pouvez également choisir d'imposer un protocole spécifique. Par exemple, avec la configuration suivante, l'agent détecte uniquement les en-têtes de requête définis par le protocole Jaeger pour les appels entrants. Si les en-têtes sont introuvables, il ne vérifie pas les autres protocoles, mais génère plutôt un nouveau contexte de trace.

Stratégie d'extraction et d'injection du contexte de trace : Le comportement par défaut consiste à extraire le contexte de trace des services en amont et à l'injecter dans les requêtes en aval. Vous pouvez configurer le comportement d'extraction et d'injection à l'aide de ce paramètre.

Objectif :

Vous pouvez sélectionner un protocole de propagation du contexte de trace prioritaire ou imposé. Les cas d'utilisation courants incluent :

• Une requête contient des contextes de trace dans plusieurs formats et l'ordre d'analyse par défaut ne répond pas à vos exigences. Vous souhaitez donner la priorité à un protocole spécifique. Par exemple, si une requête contient à la fois des contextes de trace W3C et Zipkin, l'agent analyse par défaut le contexte de trace W3C en premier. Vous pouvez définir le protocole de propagation sur Zipkin pour analyser le protocole Zipkin en priorité.

• Une requête contient un en-tête de protocole de trace, mais vous ne souhaitez pas le réutiliser et voulez générer un nouveau contexte de trace basé sur un autre protocole. Par exemple, si une requête contient un contexte de trace Zipkin, le contexte de trace Zipkin est analysé par défaut. Vous pouvez définir le protocole de propagation sur W3C et le mode de propagation sur Imposé (Enforced). Ainsi, le contexte de trace Zipkin est ignoré et un nouveau contexte est généré selon la spécification du protocole W3C. Notez que si le mode de propagation n'est pas défini sur Imposé, l'agent tente toujours d'analyser le contexte Zipkin après l'échec de l'analyse du contexte W3C prioritaire.

Effet :

Après configuration, chaque LocalRootSpan possède un attribut trace.protocol.type qui indique le protocole de trace utilisé.

Configuration de la file d'attente de messages

Dans la section Message queue configuration, vous pouvez personnaliser les informations sur le consommateur.

• Custom RabbitMQ consumer : Spécifiez le nom de classe d'un consommateur personnalisé ou d'une classe contenant un consommateur interne anonyme pour afficher la trace de ce consommateur. Séparez les noms de classes de consommateurs multiples par des virgules (,).

• Custom Kafka consumption method : Définissez une méthode de consommation personnalisée pour afficher les traces et les métriques lors de la consommation de messages avec le SDK Kafka natif.

• Automatically propagate context for Kafka messages : Lors de l'envoi d'un message, ajoutez automatiquement des en-têtes au message Kafka pour corréler les traces du producteur et du consommateur.

Configuration de la collecte de l'agent

Dans la section Agent collection configuration, vous pouvez définir le nombre maximal de spans collectés par seconde, le seuil QPS maximal que l'agent peut gérer et le niveau de journalisation de l'agent.

• Collect traces : Contrôle si les données de trace sont rapportées. Cette fonctionnalité est activée par défaut. Si vous la désactivez, l'agent cesse de rapporter les données de trace.

• Maximum spans collected per second : Nombre de spans que l'agent peut rapporter par seconde. Pour des raisons de performance, le seuil effectif réel peut s'écarter du seuil configuré jusqu'à 5 %. Les spans dépassant la limite ne sont pas rapportées.

• Maximum QPS threshold for the agent : Nombre de requêtes que l'agent peut traiter par seconde. Pour des raisons de performance, le seuil effectif réel peut s'écarter du seuil configuré jusqu'à 5 %. L'agent ne surveille pas les requêtes dépassant ce seuil. Par conséquent, aucun span n'est généré et aucune métrique n'est enregistrée pour ces requêtes, et la fonctionnalité d'association log-TraceId ne prend pas effet.

• Collect internal call data without an entry point : Dans ARMS, un point d'entrée peut être un service HTTP, un service RPC, une tâche planifiée ou une consommation de messages. Les appels tels que les appels de base de données et les requêtes HTTP sortantes qui se produisent dans la logique métier de ces points d'entrée sont considérés comme des appels internes avec un point d'entrée. En revanche, les appels HTTP périodiques, les appels de base de données, les appels NoSQL, l'envoi de messages et les appels RPC initiés par les pools de threads JDK sont considérés comme des appels internes sans point d'entrée. À partir de la version 4.2.2 de l'agent, vous pouvez filtrer ce type de données en un clic. Par exemple, le framework Lettuce exécute périodiquement des commandes pour maintenir la connexion à Redis saine. Il s'agit d'appels internes sans point d'entrée. Après avoir désactivé la collecte, l'agent ne collecte plus les données associées.

  Par exemple, sur la page NoSQL Analysis, les données d'appel générées par les commandes Redis telles que PING, QUIT et AUTH qui sont exécutées automatiquement par le framework Lettuce ne seront plus affichées.

• Agent log level : Ajuste le niveau de journalisation de l'agent pour le dépannage.

• Report agent logs : Permet à l'agent de rapporter ses journaux opérationnels au serveur ARMS pour un dépannage rapide. Dans des circonstances normales, l'agent ne rapporte qu'un petit nombre de journaux par minute.

• Enable HTTPS reporting : Lorsqu'elle est activée, l'agent utilise HTTPS pour rapporter les données.

• Default metric collection filter : Filtre le rapport des types de métriques spécifiés. Les types suivants sont actuellement pris en charge et vous pouvez sélectionner plusieurs options :

  • custom_entry : Métriques personnalisées pour la surveillance des méthodes.

  • http : Métriques du serveur HTTP.

  • http_client : Métriques du client HTTP.

  • rpc : Métriques du serveur RPC.

  • rpc_client : Métriques du client RPC.

  • sql : Métriques liées à l'accès à la base de données.

  • nosql : Métriques liées à l'accès au service NoSQL.

  • cache : Métriques liées à l'accès au service de cache.

  • producer : Métriques liées à l'envoi de messages.

  • consumer : Métriques liées à la consommation de messages.

  • schedule : Métriques liées aux services de planification.

• Custom Metric Collection Configuration : Configure la collecte des métriques définies par le SDK OpenTelemetry. Pour plus d'informations, consultez la rubrique Personnaliser les métriques à l'aide du SDK Java OpenTelemetry.

• Baggage to collect : Si votre application utilise baggage, ce paramètre écrit des éléments baggage spécifiques dans les attributs du span, facilitant ainsi la récupération de traces spécifiques.

Configuration avancée du filtrage des exceptions

Dans la section Advanced exception filtering configuration, vous pouvez configurer les règles de collecte des exceptions.

• Collect plugin exceptions : Spécifie s'il faut collecter les exceptions de plugin.

• Stack depth for differentiating similar exceptions : La valeur par défaut est 2. Cette profondeur de pile est utilisée pour identifier des types d'exceptions similaires. La modification de ce paramètre peut entraîner un comportement statistique inattendu. Procédez avec prudence.

• Exception filtering whitelist :

  Si vous ne souhaitez pas voir certaines exceptions dans l'onglet Exception Analysis, vous pouvez saisir les noms de classe complets des exceptions que vous souhaitez masquer. Ces exceptions ne sont pas comptabilisées et n'apparaissent pas sur la page Exception Analysis.

  Données affectées : Métriques de comptage des exceptions (arms_exception_requests_count_raw et arms_exception_requests_seconds_raw) et informations sur les exceptions dans les spans.

  Fonctionnalités affectées : Les métriques pour les exceptions correspondantes dans l'onglet Exception Analysis.

  Format : Utilisez le nom de classe complet pour identifier une exception à filtrer. Pour filtrer plusieurs exceptions, séparez leurs noms de classe par des virgules (,).

  Exemple : java.lang.InterruptedException,java.lang.IndexOutOfBoundsException

  Par défaut : Aucun

• Inherit from parent class for exception filtering : Lorsqu'elle est activée, si une exception collectée est une sous-classe d'une classe d'exception figurant dans la Exception filtering whitelist, l'agent la filtre également.

  Effet : Les exceptions répondant aux critères de filtre ne sont pas affichées dans la console ARMS.

• Exception message filtering : Une fois configuré, les exceptions d'un type spécifié sont également filtrées si leur champ message répond aux conditions configurées.

  • Exception name : Le type d'exception auquel le filtre s'applique.

  • Message condition : La condition pour le message d'exception, qui peut être startsWith, endsWith ou contains.

  • Message keyword : La chaîne de mot-clé.

  Effet : Les exceptions répondant aux critères de filtre ne sont pas affichées dans la console ARMS.

Configuration de la surveillance des pools

Dans la section Pool monitoring configuration, vous pouvez configurer les règles de collecte pour les pools de threads et les pools de connexions.

• Thread pool and connection pool monitoring : Active la surveillance des métriques des pools de threads pour des frameworks tels que Tomcat, Dubbo et HSF. Vous devez mettre à jour l'agent vers la dernière version.

• Thread pool thread name pattern extraction policy : Par défaut, cette option remplace tous les caractères numériques dans le nom de tout thread en cours d'exécution au sein d'un pool de threads par un astérisque (*). Vous pouvez également la configurer pour remplacer uniquement les caractères numériques situés à la fin par un astérisque (*). Si votre application démarre plusieurs fournisseurs Dubbo sur différents ports, la stratégie par défaut peut regrouper leurs pools de threads distincts en un seul, car les modèles de noms de threads extraits sont identiques. Ajustez cette stratégie pour les distinguer.

  Effet : Pour un pool de threads Tomcat typique, le modèle de nom de thread affiché est http-nio-*-exec-* par défaut. Après ajustement, il devient http-nio-9099-exec-*.

• Thread pool usage scenario filtering et Thread pool thread name pattern filtering : Filtrez les métriques de surveillance de certains pools de threads en fonction de leurs scénarios d'utilisation et des modèles de noms de leurs threads.

  Remarque

  Cette configuration n'est effective qu'à partir de la version V4.2.0 de l'agent Java.

  • Scénario d'utilisation du pool de threads : Le contexte dans lequel le pool de threads est utilisé. Les scénarios pris en charge incluent Tomcat, Vert.x, Undertow, Dubbo, Jetty, AliyunJavaAgent et default. AliyunJavaAgent représente le pool de threads utilisé par l'agent lui-même, et default représente les autres pools de threads non classés.

  • Modèle de nom de thread du pool de threads : Le modèle dérivé des noms des threads dans le pool. Par exemple, http-nio--exec- est un modèle généralement obtenu en remplaçant les parties numériques des noms de threads réels par un astérisque (*).

  Données concernées : Métriques des pools de threads

  Fonctionnalités concernées : L'onglet Thread Pool Monitoring et les alertes configurées sur la base des métriques des pools de threads.

  Format :

  • Filtrage par scénario d'utilisation du pool de threads : Saisissez les scénarios d'utilisation affichés dans l'onglet de surveillance des pools de threads. Pour saisir plusieurs scénarios, séparez-les par des virgules (,).

  • Filtrage par modèle de nom de thread du pool de threads : Saisissez les modèles de noms de threads affichés dans l'onglet de surveillance des pools de threads. Pour saisir plusieurs modèles, séparez-les par des virgules (,). Cette opération utilise une correspondance exacte et ne prend pas en charge la correspondance basée sur des règles.

  Exemple :

  • Filtrage par scénario d'utilisation du pool de threads : AliyunJavaAgent,Jetty

  • Filtrage par modèle de nom de thread du pool de threads : Catalina-utility-*,DubboServerHandler-*-thread-*

  Cela signifie que l'agent ne signalera aucune donnée de pool de threads pour le scénario AliyunJavaAgent. Pour les autres scénarios, si le modèle de nom d'un pool de threads est Catalina-utility-*, l'agent ne le signalera pas non plus.

  Par défaut : Aucun

Configuration des attributs de span

• Record OTel Specification attributes : La spécification OpenTelemetry définit les attributs qu'une span pour chaque type de plugin doit contenir. Pour réduire le volume de données rapportées, l'agent ARMS n'enregistre pas tous ces attributs par défaut. Vous pouvez activer cette option selon vos besoins. Pour plus d'informations sur les attributs ajoutés pour chaque framework après l'activation de cette option, consultez la spécification OpenTelemetry.

  Pour une span de serveur HTTP, l'activation de ce commutateur ajoute les attributs suivants.

  Les attributs ajoutés incluent des informations HTTP telles que http.path, http.scheme et http.target, ainsi que des informations réseau telles que net.host.name, net.host.port, net.protocol.name, net.protocol.version, net.sock.peer.addr et net.sock.peer.port.

• Span association with application tags : Contrôle quelles spans sont étiquetées avec les tags d'application que vous avez liés sur la page Applications. Par défaut, toutes les spans incluent des tags d'application. Pour réduire le volume d'utilisation, vous pouvez choisir d'attacher les tags d'application uniquement aux spans d'entrée. Les spans d'entrée incluent généralement HTTP Server, RPC Server, la consommation de files d'attente de messages et les tâches planifiées.

  Par exemple, si une application possède un tag d'application test1:value1 et que vous configurez son attachement uniquement aux spans d'entrée :

  Pour une span d'entrée, vous pouvez voir les attributs du tag correspondant.

  Pour une span qui n'est pas une span d'entrée, elle ne contient pas l'attribut test1:value1.

Paramètres avancés

Dans la section Advanced settings, vous pouvez configurer des paramètres tels que les interfaces à filtrer et la longueur maximale de la pile de méthodes.

• Quantile statistics : Spécifie s'il faut activer les statistiques de quantiles.

• Maximum method stack length : La valeur par défaut est de 128 frames et la valeur maximale est de 400 frames.

• Trace compression : Spécifie s'il faut simplifier les appels répétitifs, tels que ceux effectués dans une boucle for.

• Maximum display length of request input parameters : La longueur par défaut est de 512 caractères et la longueur maximale prise en charge est de 2 048 caractères.

• Asynchronous context propagation scan package : Ajoutez un package de scan pour la propagation du contexte asynchrone afin de surveiller les tâches asynchrones. Lorsqu'un nouvel objet d'une interface Runnable, Callable ou Supplier dans le package est créé, il capture automatiquement le contexte de trace du thread actuel. Ce contexte est ensuite utilisé lors de l'exécution du thread asynchrone, complétant ainsi la trace.

• Include TraceId in HTTP response : Uniquement pour les requêtes HTTP, cela renvoie le champ eagleeye-traceid dans l'en-tête de réponse.

• JVM GC trigger root cause : Une fois activé, vous pouvez afficher la cause racine des déclenchements du garbage collection (GC) de la JVM. Vous pouvez consulter les détails de la surveillance sur la page JVM Monitoring. Pour plus d'informations sur les causes de déclenchement du GC, consultez Métriques liées au GC.

Copier les configurations vers d'autres applications

Si vous devez appliquer la même configuration à d'autres applications, vous pouvez copier les paramètres.

Configuration par défaut globale

Vous pouvez enregistrer la configuration actuelle en tant que configuration par défaut globale. Cette configuration s'applique alors par défaut lorsque vous créez de nouvelles applications.

1. En bas de la page, cliquez sur Save Current App Settings as Global Default Configuration.

2. Si la boîte de dialogue Current settings not saved apparaît, cliquez sur OK pour enregistrer la configuration de l'application actuelle, puis cliquez à nouveau sur Save Current App Settings as Global Default Configuration.

3. Dans la boîte de dialogue qui s'affiche, cliquez sur Confirm.

FAQ