Le monitoring JMX, utile jusqu’à quel point?

J’ai toujours été sceptique au sujet du monitoring JMX, en grande partie parce que je pensais qu’il occupait souvent la mauvaise position de pilier des softwares de monitoring d’application. Une application à mes yeux est une palette de services ou transactions professionnels que les utilisateurs  exécutent, qui amènent ensuite le code d’application à requérir et traiter des données. Sans visibilité sur la performance des business transactions et l’exécution du code, le monitoring JMX peut-être perçu comme un outil de monitoring d’infrastructure comme les autres pour le JVM. Cependant, quand l’application et le monitoring JMX sont combinés en un seul outil, ils peuvent offrir de puissantes possibilités pour gérer la performance de l’application.

Qu’est-ce que le monitoring JMX?

Le monitoring JMX est exécuté en requérant des données de « Managed Beans » (MBeans) qui sont visibles depuis un port JVM (console JMX). Un MBean est une ressource fonctionnant à l’intérieur de JVM et fournit des données sur la configuration et l’usage de cette ressource. Les MBeans sont typiquement regroupés dans des « domaines » pour indiquer où les données sont rattachées. Dans un JVM, vous verrez typiquement des domaines multiples. Par exemple, pour une application fonctionnant sur tomcat, vous verrez les domaines « Catalina » et « Java.lang ». « Catalina » expose des ressources et des MBeans liés au conteneur Apache Tomcat, et « Java.lang » expose les mêmes pour le run-time JVM (par exemple Hotspot). Vous pouvez également voir des domaines personnalisés qui appartiennent à une application, car il est banal d’écrire des MBeans personnalisés via l’interface JMX.

Un grand problème dans la gestion de la performance de l’application est que chaque application est unique et différente. Quelques applications sont petites et demandent une faible quantité de ressources, alors que d’autres sont grandes et requièrent une quantité significative de ressources. Alors que le code de l’application est souvent optimisé durant le cycle de vie du développement, on ne peut en dire autant pour le run-time JVM et le conteneur. Oui, beaucoup d’institutions vont réduire la taille du monceau de mémoire, ou peut-être les collections à jeter – mais beaucoup vont uniquement déployer leur application avec la configuration par défaut. La plupart du temps, ça va; mais comme vous le verrez avec l’exemple d’un client ci-dessous, la configuration JVM/conteneur peut souvent être une cause ordinaire de performance lente car il n’y a pas assez de ressources disponibles pour l’application.

Le goulot du pool de connexion à la base de données:

Cet exemple nous vient d’un client récent qui a pu résoudre un goulot majeur sur son application et qui a en fait démontré la force de l’application et du monitoring JMX en action. Le client a, à cette occasion, identifié qu’une business transaction « Retrive Carrier » prenait plus de 40 secondes pour s’achever. Dans la capture d’écran ci-dessous, vous pouvez voir comment cette business transaction individuelle s’exécute sur l’infrastructure. Notez en particulier que 38 secondes ont été nécessaires pour l’accès à la base de données « OracleDB1 ». A ce stade, vous pouvez imaginer qu’il s’agit uniquement d’une instruction SQL qui a besoin d’un ou deux index.

Si nous plongeons un peu plus dans le « ws » JVM qui appelle « OracleDB1 », nous pouvons voir que le principal hotspot responsable du temps de réponse est le Spring Bean factoryPersistanceTarget :findAdminlevelCarriers qui fait différents appels JDBC.

Si nous plongeons dans l’activité JDBC, nous pouvons voir que les appels JDBC qui sont faits et que nous pouvons voir à 19.2 secondes le sont en « Get Pooled Connection ». Ceci informe l’utilisateur que la business transaction « Retrieve Carrier » a attendu 19.2 secondes pour une connexion à la base de données Oracle, causant ainsi une grande latence. Regardez comment la requête SQL a pris seulement 99ms, ce qui veut dire que le problème ici n’est pas lié à la requête ou à la base de données.

Nous pouvons confirmer qu’il y a un goulot de pool de connexion en regardant la capture d’écran ci-dessous, qui nous montre des mesures de la console JVM JMX concernant l’exploitation du pool de connexion à la base de données qui est appelée par l’application. La ligne verte sur le tableau montre le nombre maximum autorisé de connexions à la base de données (50), alors que la ligne bleue montre le nombre de connexions réelles à la base de données que l’application a effectué. Vous pouvez voir que le nombre de connexions réelles égale parfois le nombre de connexions autorisées, quand les business transactions doivent attendre jusqu’à ce que les connexions soient effectuées. C’est pourquoi certaines business transactions « Retrive Carrier » attendent 20 secondes pour des connexions à une base de données et d’autres pas. Dans cet exemple, le client a augmenté à 75 la taille du pool de connexion à la base de données, ce qui a complètement annulé le goulot.

Il s’agit uniquement d’un simple exemple sur la manière dont la combinaison entre le monitoring d’application et le monitoring JMX peut aider les institutions à trouver la cause d’un problème lié à la performance de l’application. Cependant, JMX monitoring, fonctionnant seul, vous livrera uniquement la moitié de la solution. Sans monitoring d’application, vous resterez aveugle à l’impact business et vous ne comprendrez pas quelles business transactions spécifiques et quel code d’application éreintent la ressource JVM. Vous pouvez débuter aujourd’hui en téléchargeant gratuitement AppDynamics Lite 2.0, qui fournit un monitoring d’application et un monitoring JMX pour un seul JVM. Vous pouvez également demander un essai gratuit de AppDynamics Pro pour 30 jours, qui fournit des outils plus puissants pour gérer la performance au sein de votre application distribuée complète.

App Man.