Avec la multiplication des logiciels basés sur Java, vous avez tout intérêt à vous équiper.
Aujourd’hui, nous vous proposons une présentation de JMXterm, un utilitaire en ligne de commande qui permet d’interroger les compteurs (« beans ») de JMX.
« JMX » est l’acronyme de « Java Management eXtension« . La présentation des compteurs de cette extension doit être activée et autorisée. Selon le logiciel, la manière change mais cela revient à modifier quelques paramètres dans un fichier de configuration. Pour Cassandra, par exemple, ce sera dans le fichier cassandra-env.sh.
Penchons nous maintenant sur cet outil qui permet d’éclaircir l’exploitation de ces compteurs (ces « beans ») parfois cryptiques; Ne parle-t-on pas de « mystère beans » ?
JMX étant une extension aussi utile que populaire, il existe différents outils graphiques (le plus courant étant JConsole, distribué dans les JDK Java). JMXterm a plusieurs avantages : léger, souple et présenté sous forme de Jar (« Java ARchive), il suffit de le déposer sur une machine pour pouvoir commencer à l’utiliser.
L’exécutable se télécharge ici.
Premier lancement
Pour une utilisation locale et avec la toute dernière version disponible :
java -jar jmxterm-1.0-alpha-4-uber.jar
Note : le « uber » dans le nom de l’archive n’a rien à voir avec la société de transport urbain. C’est une « über-jar », une archive qui inclue toutes ses dépendances.
Vous vous retrouvez dans un prompt accueillant :
Welcome to JMX terminal. Type "help" for available commands. $>
« help » affiche la liste des commandes. « help nom_de_la_commande » affiche l’aide de la commande demandée.
Information sur le contexte
C’est à dire : qu’est-ce qui tourne sur la machine ? Et quelles sont les informations présentées ?
« jvms » est la commande par laquelle tout commence : elle affiche les composants locaux disponibles.
$> jvms 5248 ( ) - jmxterm-1.0-alpha-4-uber.jar 7738 (m) - org.apache.cassandra.service.CassandraDaemon 5852 ( ) - datastax-agent-5.2.1-standalone.jar ./conf/address.yaml 6798 ( ) - org.apache.spark.deploy.worker.Worker spark://machine1:7077
Vous avez donc la liste des processus Java ainsi que leur numéro de processus (« pid »), qui est indispensable pour la suite.
Pour aller plus loin, il faut se connecter à l’un de ces processus. Exemple :
$>open 7738 #Connection to 7738 is opened
Nous sommes connectés au processus Java correspondant à Cassandra.
Les informations sont classées en domaines, en type puis en périmètre. C’est important de bien comprendre cette classification car elle est reprise dans toutes les commandes.
Liste des domaines :
$>domains JMImplementation ch.qos.logback.classic com.sun.management java.lang java.nio java.util.logging org.apache.cassandra.auth org.apache.cassandra.db org.apache.cassandra.internal org.apache.cassandra.metrics org.apache.cassandra.net org.apache.cassandra.request org.apache.cassandra.service org.apache.cassandra.transport
Quels sont les beans disponibles ? Il y en a vraiment beaucoup (2000+ pour le seul domaine « org.apache.cassandra.metrics »). Voici ceux pour le domaine « org.apache.cassandra.net » :
$>beans -d org.apache.cassandra.net #domain = org.apache.cassandra.net: org.apache.cassandra.net:type=FailureDetector org.apache.cassandra.net:type=Gossiper org.apache.cassandra.net:type=MessagingService org.apache.cassandra.net:type=StreamManager
Et pour récupérer un compteur en particulier ?
A partir de là, on peut voir quelles informations sont disponibles grâce à « get ».
Par exemple, cherchons à voir les informations concernant le commitlog Cassandra sur lequel nous sommes connectés. « Commitlog » est un type du domaine « org.apache.cassandra.db ».
Note : Avec ce genre de syntaxe et de vocabulaire, il est plus facile de comprendre pourquoi les développeurs Java sont si fatigués…
La commande à passer :
$>get -d org.apache.cassandra.db -b org.apache.cassandra.db:type=Commitlog *
Celle-ci vous retourne :
#mbean = org.apache.cassandra.db:type=Commitlog: CompletedTasks = 97916; PendingTasks = 0; TotalCommitlogSize = 436207616; ArchiveCommand = ; RestoreCommand = ; RestoreDirectories = ; RestorePointInTime = 9223372036854775807; RestorePrecision = MICROSECONDS; ActiveSegmentNames = ( CommitLog-4-1490606629314.log, CommitLog-4-1490606629315.log, CommitLog-4-1490606629316.log, CommitLog-4-1490606629317.log, CommitLog-4-1490606629318.log, CommitLog-4-1490606629322.log, CommitLog-4-1490606629323.log, CommitLog-4-1490606629324.log, CommitLog-4-1490606629329.log, CommitLog-4-1490606629330.log, CommitLog-4-1490606629331.log, CommitLog-4-1490606629333.log ); ArchivingSegmentNames = ( );
Il y a donc 10 compteurs nommés (« RestoreCommand », « PendingTasks »…) et le « * » en fin de commande permettait de les collecter en une seule fois, comme une sorte de super chasseur de Pokemon.
Pour obtenir la valeur d’un seul compteur, il suffit de remplacer « * » par son nom.
Vous pouvez également vous simplifier la vie en configurant votre environnement JMXTerm : « $> domain mon_domaine » exporte le nom du domaine par défaut à utiliser, « bean mon_bean » fait la même chose pour le bean par défaut. Pensez à les remettre à zéro à l’aide de « $> domain * » ou « $> bean * ».
Et pour faire la même chose à distance ?
Excellent question, public silencieux mais pertinent.
Évidemment, l’exploitation d’un cluster impose une centralisation des commandes d’administration. Rafraîchissez vous la mémoire avec notre article sur l’excellent DSH et les autres (non moins excellents) shells distribués.
JMXterm permet de se connecter sur le RMI (« Remote Management Interface ». Rien à voir avec vos finances).
La syntaxe est d’une clarté exemplaire dans notre monde si compliqué :
java -jar jmxterm.jar --url service:jmx:rmi://machine_cible/jndi/rmi://machine_cible:port_remote_jmx/jmxrmi
Clair, n’est-ce pas ?
Non. C’est une syntaxe hideuse mais d’une grande beauté intérieure.
Toujours est-il qu’une fois connecté, vous aurez accès à tous les services ouverts aux requêtes distantes.
Pour vous aider, les programmes indiquent dans les logs les informations des connexions JMX : adresse où il écoute, port utilisé. C’était en tout cas comme ça pour Cassandra et Kafka.
Conclusion
Voilà pour le principe de base.
Sachez qu’il est possible – et même conseillé – de regrouper les commandes dans des fichiers. Et que c’est ainsi que procèdent les outils de monitoring comme Nagios. Une collecte automatisée suivie d’un stockage dans ElasticSearch vous donne un outil de plus pour évaluer la santé de vos applications basées sur Java. Même si vous ne faites qu’archiver les mesures de la JVM (Garbage Collection et autres), cela vaut la peine de vous y intéresser.
Entre nous, il n’y a aucune raison de relever ces compteurs manuellement. Par contre, il est intéressant de les connaître afin de mieux maîtriser votre supervision.
Sinon, c’est le binz…
Des problèmes ? des questions ? Exprimez-vous ! Les commentaires sont ouverts. Coquilles et fautes de grammaires sont notre lot quotidien : signalez-les nous à m.capello@dbsqware.com