Application Real-Time Monitoring Service:Instance monitoring for Java applications

Métriques par environnement

Les métriques disponibles varient selon que votre application s'exécute sur ECS ou dans des conteneurs, et selon l'intégration ou non de l'environnement de conteneurs avec Managed Service for Prometheus.

Métriques des graphiques de tendance

Pour les environnements ECS, utilisez la liste déroulante à côté du titre de chaque graphique d'infrastructure pour basculer entre les valeurs moyennes et maximales.

Pour les graphiques GC, alternez entre le nombre de GC et la durée moyenne de GC. Pour les graphiques de mémoire JVM, basculez entre les vues de mémoire heap et non-heap.

Colonnes de la liste des instances

Dans l'environnement Conteneur (Prometheus), l'utilisation du CPU, de la mémoire et du disque affiche - lorsqu'aucune limite n'est définie pour la ressource.

Exigences pour l'environnement de conteneurs

• Avec Managed Service for Prometheus : les métriques de conteneur proviennent de Managed Service for Prometheus. Pour configurer l'intégration, consultez la section Container Observability.

• Sans Managed Service for Prometheus : mettez à niveau la sonde Application Monitoring vers la version 4.1.0 ou ultérieure. Les versions antérieures de la sonde ne rapportent pas les métriques de base des conteneurs. Pour plus de détails sur les versions de la sonde, consultez le Guide des versions de la sonde (Java Agent).

Interactions avec les graphiques

Chaque graphique de tendance prend en charge deux actions :

• Cliquez sur pour afficher les statistiques des métriques sur une plage de temps ou comparer la même plage de temps sur différentes dates.

• Cliquez sur pour basculer entre les graphiques en colonnes et les graphiques de tendance.

Actions dans la liste des instances

• Cliquez sur une IP d'instance (ou sur Details dans la colonne Actions pour les environnements de conteneurs) pour ouvrir les détails de l'instance.

• Cliquez sur Trace dans la colonne Actions pour afficher les détails de la trace. Pour plus d'informations, consultez la section Analyse des traces.

Vue d'ensemble

L'onglet Overview affiche le nombre de requêtes, le nombre d'erreurs, le temps de réponse moyen et les informations sur les appels lents pour l'interface sélectionnée.

La Host List située à gauche vous permet de basculer entre les hôtes pour consulter les données de surveillance. Les cartes récapitulatives affichent les variations en pourcentage d'un jour sur l'autre. Sous les cartes, des graphiques de tendance chronologiques affichent les métriques Requests/1m, Errors/1m et Response Time/1m avec une granularité à la minute. La page comprend également les onglets JVM Monitoring, Host Monitoring et Trace Analysis.

Surveillance JVM

L'onglet JVM Monitoring affiche les métriques de GC, de mémoire, de threads et de descripteurs de fichiers pour l'instance sélectionnée.

La section GC contient les graphiques Full GC Count/1m, Young GC Count/1m, Full GC Trigger Reason/1m et Young GC Trigger Reason/1m. La section mémoire contient les graphiques Memory Usage Distribution/1m, Heap Memory/1m, Heap Memory (used)/1m et d'autres. Le panneau de gauche vous permet de sélectionner une instance d'application spécifique pour afficher ses données de surveillance.

Surveillance des pools de threads

La surveillance des pools de threads suit la configuration des threads principaux, l'état des threads actifs et les métriques d'exécution des tâches. Filtrez les pools de threads par type et par nom en haut de l'onglet.

Surveillance des pools de connexions

La surveillance des pools de connexions suit la configuration d'initialisation et l'état des connexions en cours d'exécution. Filtrez les pools de connexions par type en haut de l'onglet.

Surveillance de l'hôte

L'onglet Host Monitoring affiche les métriques de CPU, de mémoire, de disque, de charge, de trafic réseau et de paquets réseau.

Surveillance des conteneurs

L'onglet Container Monitoring affiche les métriques de ressources au niveau du conteneur. Les métriques disponibles dépendent de votre méthode d'intégration :

L'onglet Container Monitoring affiche une zone Overview avec Namespace, Cluster et les métriques récapitulatives CPU (cœurs) et Memory avg/max/last/Limit. En dessous, la zone Resource contient les quatre graphiques linéaires suivants :

• Memory/Limit(%)

• Memory Usage

• CPU Usage(%)

• CPU Usage By Cores (avec des courbes user/system/total)

Analyse des traces

L'analyse des traces interroge les données de traces stockées en temps réel. Combinez les filtres et les dimensions d'agrégation pour diagnostiquer les problèmes de performance dans différents scénarios. Pour plus de détails, consultez la section Analyse des traces.

Dans la console Tracing, saisissez des critères de recherche tels que serviceName: "mall-gateway" pour interroger les données de traces. La page contient :

• Panneau de filtre rapide à gauche : filtrez par Status, Duration (plage du curseur 0 ns–5 s), Interface Name et Host Address.

• Graphiques statistiques supérieurs : histogramme Call Count, histogramme Errors/HTTP Errors, graphique linéaire Average Duration.

• Tableau de données Span inférieur : les colonnes incluent TraceId, Interface Name, Application Name, Duration, Status, Start Time, Host Address. Cliquez sur Details ou Logs pour afficher les détails de la trace.

• Panneau Slow Trace Analysis à droite : affiche les spanNames les plus contributifs en termes de durée.

Pourquoi le trafic est-il inégal entre les instances ?

Dans la version 3.x de la sonde, l'activation de l'optimisation de la mémoire peut entraîner l'omission de certaines métriques. Mettez à niveau vers la version 4.x de la sonde.

Pourquoi une seule requête Undertow est-elle comptée deux fois ?

Dans les versions de la sonde antérieures à 3,2.x, l'instrumentation DeferredResult entraîne l'enregistrement double d'un appel. Mettez à niveau vers la version 3.2.x ou ultérieure de la sonde.

Pourquoi les quotas de CPU ou de mémoire dans Container Monitoring ne correspondent-ils pas aux paramètres du Pod ?

Vérifiez si le Pod définit plusieurs conteneurs. Cette métrique correspond à la somme des quotas de tous les conteneurs du Pod.

Pourquoi certaines métriques système sont-elles manquantes, imprécises ou affichent-elles une utilisation du CPU à 100 % ?

Les versions de la sonde antérieures à 4.x ne collectent pas les métriques système sous Windows. Mettez à niveau vers la version 4.x ou ultérieure de la sonde.

Pourquoi un Full GC se produit-il juste après le démarrage de l'application ?

La taille par défaut de l'espace metaspace est d'environ 20 Mo. Lors du démarrage, l'expansion de l'espace metaspace déclenche un Full GC. Définissez les tailles initiale et maximale de l'espace metaspace à l'aide des paramètres -XX:MetaspaceSize et -XX:MaxMetaspaceSize.

Comment VM Stack est-il calculé ?

VM Stack est calculé en multipliant le nombre de threads actifs par 1 Mo (la taille de pile de threads par défaut). Si vous définissez une taille de pile différente avec -Xss, cette métrique peut ne pas correspondre à la valeur réelle.

Comment les métriques JVM sont-elles collectées ?

ARMS récupère les métriques JVM à l'aide des interfaces JDK standard.

Métriques de mémoire :

• ManagementFactory.getMemoryPoolMXBeans

• java.lang.management.MemoryPoolMXBean#getUsage

Métriques GC (sonde antérieure à 4.4.0) :

• ManagementFactory.getGarbageCollectorMXBeans

• GarbageCollectorMXBean#getCollectionCount

• GarbageCollectorMXBean#getCollectionTime

Métriques GC (sonde 4.4.0 ou ultérieure) :

Récupérées en s'abonnant à l'événement GarbageCollectionNotificationInfo de GarbageCollectorMXBean.

Pourquoi la valeur maximale de la mémoire heap JVM est-elle -1 ?

Une valeur de -1 signifie que la taille maximale de la heap n'est pas configurée. Définissez-la à l'aide du paramètre -Xmx.

Pourquoi l'utilisation de la mémoire heap JVM n'est-elle pas égale à la taille maximale de la mémoire heap ?

Le paramètre -Xms définit la taille initiale de la heap. La JVM étend la heap selon les besoins, jusqu'au maximum défini par -Xmx. Une différence indique que la heap n'est pas encore entièrement étendue.

Pourquoi la fréquence de GC JVM augmente-t-elle progressivement ?

Cela se produit généralement avec ParallelGC, l'algorithme de GC par défaut dans JDK 8. ParallelGC active -XX:+UseAdaptiveSizePolicy par défaut, ce qui ajuste dynamiquement la taille de la heap. Lorsque Young GC s'exécute fréquemment, l'espace survivant peut diminuer, provoquant une promotion plus rapide des objets vers l'ancienne génération. Cela accélère la croissance de l'ancienne génération et déclenche des Full GC plus fréquents. Pour plus de détails, consultez la documentation Java GC Ergonomics.

Pourquoi n'y a-t-il aucune donnée pour la surveillance des pools de threads ou de connexions ?

1. Sur la page Custom Configuration , sous Advanced Settings , confirmez que la surveillance des pools de threads et de connexions est activée.

2. Vérifiez que le framework est pris en charge. Consultez la section Surveillance des pools de threads et de connexions.

Pourquoi le nombre maximal de connexions HikariCP ne correspond-il pas aux attentes ?

Les versions de la sonde antérieures à 3,2.x récupèrent incorrectement le nombre maximal de connexions. Mettez à niveau vers la version 3.2.x ou ultérieure de la sonde.

Pourquoi les métriques de surveillance des pools s'affichent-elles sous forme de valeurs décimales ?

La sonde collecte les données toutes les 15 secondes. La console affiche la moyenne sur la plage de temps sélectionnée. Par exemple, si quatre points de données en une minute sont 0, 0, 1 et 0, la valeur affichée est 0,25.

Pourquoi les pools de threads ou de connexions sont-ils pleins, mais la surveillance n'indique-t-elle aucun changement ?

ARMS collecte les métriques des pools de threads et de connexions toutes les 15 secondes. Les pics de courte durée dans cet intervalle peuvent ne pas être capturés.

Pourquoi le nombre maximal de threads du pool de threads est-il inattendu ou affiche-t-il 2,1 milliards ?

ARMS lit directement le nombre maximal de threads depuis l'objet du pool de threads. Une valeur de 2,1 milliards indique généralement un pool de threads planifié, qui utilise par défaut Integer.MAX_VALUE.

/**
 * Creates a new ScheduledThreadPoolExecutor with the given core pool size.
 * @param corePoolSize the number of threads to keep in the pool, even if they are idle,
 *        unless allowCoreThreadTimeOut is set
 * @throws IllegalArgumentException if corePoolSize < 0
 */
public ScheduledThreadPoolExecutor(int corePoolSize) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue());
}

/**
 * Creates a new ScheduledThreadPoolExecutor with the given initial parameters.
 * @param corePoolSize the number of threads to keep in the pool, even if they are idle,
 *        unless allowCoreThreadTimeOut is set
 * @param threadFactory the factory to use when the executor creates a new thread
 * @throws IllegalArgumentException if corePoolSize < 0
 * @throws NullPointerException if threadFactory is null
 */
public ScheduledThreadPoolExecutor(int corePoolSize,
                        ThreadFactory threadFactory) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue(), threadFactory);
}

Pourquoi les métriques du pool de threads Tomcat ne correspondent-elles pas aux attentes ?

Si plusieurs métriques (nombre maximal de threads, nombre de threads actifs, nombre de threads principaux) diffèrent toutes des valeurs attendues, vérifiez si l'application expose les services Tomcat sur plusieurs ports. Par exemple, Spring Actuator ouvre un port supplémentaire pour les métriques. Dans ce cas, ARMS peut fusionner les métriques de plusieurs pools de threads en raison de la convergence des dimensions.

Pour résoudre ce problème, mettez à niveau vers la version 4.1.10 ou ultérieure de la sonde. Ensuite, accédez à Application Configuration > Custom Configuration > Pooling Monitoring Configuration , et définissez Thread Pool Thread Name Pattern Extraction Strategy sur Replace trailing digits with *.

Pourquoi n'y a-t-il aucune donnée pour un pool de threads ou de connexions avant une certaine heure ?

Cela se produit lorsqu'une tâche planifiée crée le pool. Les données n'apparaissent qu'après l'initialisation du pool par la tâche. Les métriques basées sur le trafic, telles que le nombre de requêtes API, se comportent de manière similaire.

Pourquoi n'y a-t-il aucune donnée pour les pools de connexions HttpClient ?

À partir de la version 4.x de la sonde ARMS, la surveillance des pools de connexions pour OkHttp3 et Apache HttpClient n'est plus prise en charge. Ces frameworks créent un pool de connexions distinct pour chaque domaine externe. Lorsqu'un grand nombre de domaines sont impliqués, cela entraîne une surcharge excessive et des risques de stabilité.

Pourquoi n'y a-t-il aucune donnée de surveillance des conteneurs après l'intégration d'une application ACK ?

ARMS affiche les données de surveillance des conteneurs uniquement pour les ressources appartenant au même compte Alibaba Cloud. Vérifiez que le compte utilisé pour créer le cluster ACK correspond au compte utilisé pour l'intégration ARMS.

Pourquoi le taux d'ouverture des handles de fichiers est-il non nul, mais le nombre de handles de fichiers est-il nul ?

Cela se produit sur JDK 9 ou ultérieur lors de l'utilisation de la version 3.x de la sonde ARMS. Mettez à niveau vers la version 4.2.2 ou ultérieure de la sonde. Consultez la section Mettre à niveau l'agent ARMS.

Pourquoi l'utilisation de la mémoire physique du processus JVM diffère-t-elle considérablement de l'utilisation de la mémoire heap de surveillance JVM ?

Le processus JVM utilise probablement une quantité importante de mémoire hors heap, qu'ARMS ne surveille pas entièrement. Pour plus de détails sur les zones de mémoire JVM couvertes par ARMS, consultez la section Détails de la mémoire de surveillance JVM.

Pourquoi Druid affiche-t-il plus de connexions inactives que le paramètre maximal de connexions inactives ?

Le paramètre MaxIdle dans Druid existe uniquement pour la compatibilité de migration avec DBCP. Il n'a aucun effet fonctionnel.

Pourquoi n'y a-t-il aucune donnée après la mise à niveau de certaines instances vers la dernière version de la sonde ?

Lors de la mise à niveau depuis une version de la sonde antérieure à 4,1.x, toutes les instances doivent être mises à niveau. La page s'adapte automatiquement une fois que toutes les instances exécutent la même version.