Aide en ligne du monitoring JavaMelody

Le monitoring JavaMelody est un outil de mesure et de statistiques sur le fonctionnement réel d'une application selon l'usage qui en est fait par les utilisateurs.
Le monitoring est en grande partie basé sur des statistiques de requêtes et sur des courbes d'évolution. Il permet ainsi d'améliorer les applications en recette et en production et d'aider à :

Docs Documentations

Java SE Reference at a Glance
Troubleshooting Guide for Java SE 6
Troubleshooting Guide for Java SE 5
Monitoring and Managing Java SE 6
Java SE 6 Performance
Memory Management

Stats Synthèse

Dans la page du monitoring, la synthèse présente des courbes d'évolution sur différentes valeurs de mesures.
Ces mesures sont effectuées à un instant t, par exemple toutes les 2 minutes. Chaque courbe suit l'évolution d'une valeur de mesure sur la période plus ou moins large choisie par l'intermédiaire des liens au-dessus de la synthèse : day le jour, week la semaine, month le mois ou year l'année. Dans chaque courbe sont suivies et indiquées en chiffres la valeur moyenne en vert et le maximum en bleu. Les courbes sont persistées : un redémarrage du serveur d'application n'a pas d'influence sur elles hormis un trou dans les mesures.
Chaque courbe peut être affichée en grand et redimensionnée en cliquant sur celle-ci dans la synthèse.

Les courbes présentées sont : Le lien 'Update Actualiser' permet de rafraîchir la page et les courbes. Le lien 'PDF PDF' affiche tout le rapport en format PDF pour Adobe Reader.
Si un serveur de collecte est utilisé pour afficher le monitoring de plusieurs serveurs en ferme ou en cluster, la courbe de mémoire est la somme des mémoires sur les différents serveurs, mais le pourcentage cpu est celui entre 0 et 100 pour tous les serveurs, et le nombre de sessions http est la somme des sessions sur les différents serveurs, de même que pour le nombre de threads actifs, le nombre de connexions jdbc actives ou utilisées, et les hits par minute ou le temps moyen en millisecondes.

Courbe mémoire : cas d'utilisation d'une application utilisée par intermittence (jour/nuit par exemple)

Mémoire

La courbe de la mémoire augmente rapidement quand l'application est utilisée, et elle augmente doucement mais augmente tout de même quand l'application n'est pas utilisée. Une courbe avec des pentes, comme dans l'exemple ci-dessus, est donc classique même si l'application n'est pas utilisée.
Dans tous les cas et selon la nécessité, la mémoire est finalement libérée d'un coup par le ramasse-miette (GC majeur) et revient à un niveau bas, avant de remonter plus ou moins vite. Si la résolution paramétrée est suffisamment fine, la courbe montre également les GC mineurs en petites dents de scie entre les GC majeurs. Ces GC mineurs libèrent également la mémoire mais en moins grande quantité que les GC majeurs. Il est possible de forcer un GC majeur par l'action 'Garbage collector Exécuter le ramasse-miette' dans la partie 'System informations Informations systèmes' du rapport.

Courbe mémoire : cas d'utilisation d'une saturation mémoire

Si la courbe mémoire augmente jusqu'au maximum et que l'application ne peut en libérer avec le ramasse-miette, le serveur provoque éventuellement des erreurs OutOfMemoryError pour interrompre le traitement et libérer si possible la mémoire.
Tant que la mémoire est insuffisante, le cpu reste à 100% car le ramasse-miette s'exécute en permanence. Cela peut provoquer de très fortes lenteurs et un quasi-blocage du serveur d'application.
Les solutions peuvent être d'augmenter la mémoire java maximum (paramètre Xmx au lancement du serveur), et éventuellement la mémoire physique du serveur, ou bien d'optimiser si possible la consommation mémoire de l'application.

Courbes de threads actifs et connexions jdbc actives : cas d'utilisation d'un plateau (requêtes longues)

Threads actifs

Quand une application est peu ou pas utilisée, les courbes des threads actifs et connexions jdbc actives restent à 0. En effet, la plupart des requêtes sont heureusement courtes et la plupart des mesures (effectuées toutes les 2 minutes par exemple) sont prises sans requêtes en cours, sauf 1 ou 2 de temps en temps visibles sous forme d'un pic.

Par contre, quand il y a une forme de plateau dans la courbe des threads actifs comme dans l'exemple ci-dessus, cela veut dire qu'il y a une ou plusieurs requêtes qui sont longues (plusieurs minutes ou plusieurs heures) et qui potentiellement saturent le serveur d'application ou la base de données.
Pour trouver la cause :

Stats Statistiques

Les statistiques d'un compteur présentent les statistiques des requêtes exécutées sur le serveur d'application.
Il existe 4 compteurs de requêtes aujourd'hui : Pour chaque compteur, une requête apparaît dans les statistiques quand elle est terminée; pour connaître les requêtes non terminées voir la partie 'Requêtes en cours Requêtes en cours'.
Comme pour les courbes, les statistiques des requêtes sont celles sur la période plus ou moins large choisie par l'intermédiaire des liens au-dessus des courbes : le jour (depuis 0h), la semaine, le mois ou l'année. Ainsi il est possible de voir les statistiques pour la seule journée en cours, ou par exemple pour une version de l'application déployée depuis un mois sans les statistiques des versions précédentes.
Et pour chaque compteur, le rapport présente une synthèse des statistiques pour toutes les requêtes (global), des statistiques dépassant le seuil d'alerte de niveau 1 (warning) et de celles dépassant le seuil d'alerte de niveau 2 (severe). Les détails des statistiques pour chaque requête peuvent être affichés en cliquant le lien '+ Détails'.

Chaque statistique de requête indique : et si il s'agit des statistiques http : Comme tous les tableaux du rapport, les tableaux de statistiques sont triables par ordre ascendant ou descendant en cliquant sur les entêtes de colonnes.
Les statistiques sont persistées pour chaque compteur : un redémarrage du serveur d'application n'a pas d'influence sur elles.
Si un serveur de collecte est utilisé pour afficher le monitoring de plusieurs serveurs en ferme ou en cluster, les statistiques des compteurs sont globales pour tous les serveurs.

Remarque : Dans MS Windows (sauf Vista), la résolution de l'horloge utilisée est d'environ 16 ms (soit 0, soit 16, soit 32 ms). Ainsi le temps d'une exécution n'est pas précis en-dessous de 16 ms avec Windows. Cela est en partie corrigé par l'utilisation d'une moyenne quand il y a eu suffisamment d'exécutions. Mais cela n'est pas grave puisqu'en général, les requêtes problématiques feront beaucoup plus que 16 ms.

Erreurs systèmes http Statistiques d'erreurs systèmes http

Les statistiques d'erreurs systèmes http présentent les erreurs qui remontent jusqu'au filtre http du monitoring, soit sous forme d'exceptions lancées par l'application par l'intermédiaire d'une servlet, soit sous forme d'un code d'erreur http (404 "not found" ou 500 "internal server error" par exemple, liste complète). Ces statistiques indiquent la liste des 250 erreurs systèmes les plus fréquentes avec en particulier le nombre d'occurrences de chaque erreur sur la période choisie, ainsi que le temps moyen de la requête pour chaque erreur. Seule l'erreur la plus fréquente est affichée au départ, les autres erreurs étant affichées en cliquant le lien '+ Détails'. Les dates, heures, utilisateurs et requêtes http complètes des 100 dernières erreurs sont affichées en cliquant le lien '+ Dernières erreurs'. En cliquant sur le nom d'une erreur, il est possible de voir pour cette erreur la courbe d'évolution du nombre d'occurrences au fil du temps ainsi que la stack-trace java de l'erreur quand il s'agit d'une exception java.
Ces statistiques d'erreurs permettent d'améliorer la fiabilité de l'application selon son utilisation réelle en production.

Logs d'erreurs systèmes Statistiques de logs d'erreurs systèmes

Les statistiques de logs d'erreurs systèmes présentent les logs 'warning' et 'error' inscrits par l'application (les librairies log4j d'apache et java.util.logging du jdk sont toutes les deux supportées). Ces statistiques indiquent la liste des 500 logs d'erreurs systèmes les plus fréquentes avec le nombre d'occurrences de chaque erreur sur la période choisie. Seule le log d'erreur le plus fréquent est affiché au départ, les autres logs étant affichés en cliquant le lien '+ Détails'. Les dates, heures, utilisateurs et le cas échéant requêtes http complètes des 100 dernièrs logs d'erreurs sont affichées en cliquant le lien '+ Dernières erreurs'. En cliquant sur le nom d'un log d'erreur, il est possible de voir pour ce log la courbe d'évolution du nombre d'occurrences au fil du temps ainsi que la stack-trace java de l'erreur quand une exception java a été inscrite avec le log.
Ces statistiques de logs d'erreurs permettent également d'améliorer la fiabilité de l'application selon son utilisation réelle en production.

Requêtes en cours Requêtes en cours

Les requêtes en cours présentent à l'instant de génération du rapport les exécutions de requêtes non terminées.
L'arbre des requêtes http, éventuellement ejb, spring et/ou sql est indiqué avec pour chacune des requêtes le temps déjà écoulé, le temps cpu écoulé, le nombre de requêtes sql déjà exécutées et le temps sql de ces requêtes.
Les statistiques des requêtes sont rappelées avec les requêtes en cours : temps moyen, temps cpu moyen, hits sql moyens et temps sql moyen. Cela permet de comparer les requêtes en cours avec les statistiques moyennes.
La stack-trace java courante est indiquée par un tooltip sur le thread (si jdk 1.6).
Seule la requête la plus longue est affichée au départ, les autres sont affichées en cliquant sur le lien '+ Détails'.

Informations systèmes Informations système

Les informations système indiquent à l'instant de génération du rapport des informations sur le serveur java, son état et sur le système d'exploitation du serveur.
Les principales informations sont affichées au départ : mémoire java utilisée, nombre de sessions http, nombre de threads actifs, nombre de connexions jdbc actives et nombre de connexions jdbc utilisées. Ce sont d'ailleurs des valeurs qui seront mesurées et utilisées pour les courbes.
Les autres informations, comme la version du serveur, du système d'exploitation ou de la base de données ou la mémoire du système d'exploitation, sont affichées en cliquant sur le lien '+ Détails'.

Dans cette partie des informations systèmes, des liens donnent accès aux actions systèmes : Si un serveur de collecte est utilisé pour afficher le monitoring de plusieurs serveurs en ferme ou en cluster, les informations systèmes de chaque serveur sont affichées (agrégées pour ce qui est de la liste des sessions et de l'histogramme mémoire) et les actions s'exécutent successivement sur chacun des serveurs.

Threads Threads

Ce tableau affiche simplement la liste de tous les threads dans le serveur, avec pour chacun la priorité, l'état et la stack-trace en tooltip (si jdk 1.6) entre autres.

Caches de données Caches de données

Les caches de données affichent la liste des caches dans l'application java à condition que la librairie ehcache soit utilisée pour ceux-ci.
Pour chacun des caches, des statistiques sont indiquées : le nombre d'objets en mémoire et sur disque à cet instant, l'efficacité du cache mémoire (pourcentage depuis le démarrage du serveur des demandes satisfaites par le cache en mémoire par rapport à celles satisfaites par le cache sur disque), l'efficacité du cache au global (pourcentage des demandes satisfaites par le cache en mémoire ou sur disque par rapport à toutes les demandes y compris celles non satisfaites pour les données non présentes en cache). La configuration de chaque cache est également rappelée.

Langue

Le monitoring est affiché en français ou en anglais selon la langue préférée de votre navigateur web. Si le monitoring est en langue anglaise au lieu d'être en langue française, il faut corriger la langue préférée. Par exemple, dans Firefox, ouvrir le menu et la boîte de dialogue "Outils, Options, Contenu, Langue ... Choisir" et placer "Français [fr]" en premier comme ceci :

langue


Crédits icônes

Silk, mini and flag icons (Creative Commons)

Tango icons (GPL)