Pour récupérer la valeur d'un compteur JMX particulier sur un hôte, le serveur Zabbix interroge le Java gateway de Zabbix, qui utilise à son tour l'API de gestion JMX pour interroger à distance l'application concernée.

Pour plus de détails et la configuration, consultez la section Zabbix Java gateway.

La communication entre Java gateway et l'application JMX surveillée ne doit pas être bloquée par un pare-feu.

Activation de la surveillance JMX à distance pour une application Java

Une application Java n’a pas besoin de logiciel supplémentaire installé, mais elle doit être démarrée avec les options de ligne de commande indiquées ci-dessous pour prendre en charge la surveillance JMX à distance.

Au minimum, si vous souhaitez simplement commencer par surveiller une application Java simple sur un hôte local sans sécurité appliquée, démarrez-la avec ces options :

java \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.registry.ssl=false \
-jar /path/to/your/application.jar

Cela fait que Java écoute les connexions JMX entrantes sur le port 12345, depuis l’hôte local uniquement, et lui indique de ne pas exiger d’authentification ni de SSL.

Si vous souhaitez autoriser les connexions sur une autre interface, définissez le paramètre -Djava.rmi.server.hostname sur l’adresse IP de cette interface.

Si vous souhaitez être plus strict en matière de sécurité, de nombreuses autres options Java sont à votre disposition. Par exemple, l’exemple suivant démarre l’application avec un ensemble d’options plus polyvalent et l’ouvre à un réseau plus large, pas seulement à l’hôte local.

java \
-Djava.rmi.server.hostname=192.168.3.14 \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.password.file=/etc/java-6-openjdk/management/jmxremote.password \
-Dcom.sun.management.jmxremote.access.file=/etc/java-6-openjdk/management/jmxremote.access \
-Dcom.sun.management.jmxremote.ssl=true \
-Dcom.sun.management.jmxremote.registry.ssl=true \
-Djavax.net.ssl.keyStore=$YOUR_KEY_STORE \
-Djavax.net.ssl.keyStorePassword=$YOUR_KEY_STORE_PASSWORD \
-Djavax.net.ssl.trustStore=$YOUR_TRUST_STORE \
-Djavax.net.ssl.trustStorePassword=$YOUR_TRUST_STORE_PASSWORD \
-Dcom.sun.management.jmxremote.ssl.need.client.auth=true \
-jar /path/to/your/application.jar

La plupart (sinon la totalité) de ces paramètres peuvent être spécifiés dans $JRE/lib/management/management.properties (ou à l’emplacement où se trouve ce fichier sur votre système).

Notez que si vous souhaitez utiliser SSL, vous devez modifier le script startup.sh en ajoutant les options -Djavax.net.ssl.* à Java gateway, afin qu’il sache où trouver les magasins de clés et de certificats de confiance.

Consultez Monitoring and Management Using JMX pour une description détaillée.

Configuration des interfaces et des éléments JMX dans l'interface Zabbix

Avec la passerelle Java en cours d'exécution, le serveur sachant où trouver la passerelle et une application Java démarrée avec la prise en charge de la surveillance JMX à distance, il est temps de configurer les interfaces et les éléments dans l'interface web de Zabbix.

Configuration de l'interface JMX

Commencez par créer une interface de type JMX sur l'hôte concerné.

Tous les champs de saisie obligatoires sont marqués d'un astérisque rouge.

Ajout d'un élément agent JMX

Pour chaque compteur JMX qui vous intéresse, ajoutez un élément agent JMX rattaché à cette interface.

La clé dans la capture d'écran ci-dessous est jmx["java.lang:type=Memory","HeapMemoryUsage.used"].

Tous les champs de saisie obligatoires sont marqués d'un astérisque rouge.

Les champs qui nécessitent des informations spécifiques pour les éléments JMX sont :


Type	Définissez agent JMX ici.
Key	La clé d'élément `jmx[]` contient trois paramètres : nom d'objet - le nom d'objet d'un MBean nom d'attribut - un nom d'attribut MBean avec des noms de champs de données composites facultatifs séparés par des points description courte unique - une description unique qui permet d'avoir plusieurs éléments JMX avec le même nom d'objet et le même nom d'attribut sur l'hôte (facultatif) Voir ci-dessous pour plus de détails sur les clés d'élément JMX. Vous pouvez découvrir les MBeans et les attributs MBean à l'aide d'un élément `jmx.discovery[]` de découverte de bas niveau.
JMX endpoint	Vous pouvez spécifier un endpoint JMX personnalisé. Assurez-vous que les paramètres de connexion de l'endpoint JMX correspondent à l'interface JMX. Cela peut être réalisé en utilisant les macros {HOST.*}, comme dans l'endpoint JMX par défaut. Les macros} et les macros utilisateur sont prises en charge.
User name	Indiquez le nom d'utilisateur (jusqu'à 255 caractères), si vous avez configuré l'authentification sur votre application Java. Les macros utilisateur sont prises en charge.
Password	Indiquez le mot de passe (jusqu'à 255 caractères), si vous avez configuré l'authentification sur votre application Java. Les macros utilisateur sont prises en charge.

Si vous souhaitez superviser un compteur booléen qui vaut soit "true", soit "false", indiquez alors le type d'information "Numérique (non signé)" et sélectionnez l'étape de prétraitement "Booléen vers décimal" dans l'onglet Prétraitement. Le serveur stockera alors les valeurs booléennes sous forme de 1 ou 0, respectivement.

Clés d’élément JMX plus en détails

Attributs simples

Un nom d'objet MBean n'est rien d'autre qu'une chaîne que vous définissez dans votre application Java. En revanche, un nom d'attribut peut être plus complexe. Si un attribut renvoie un type de données primitif (un entier, une chaîne, etc.), il n'y a rien de particulier à craindre, la clé ressemblera à ceci :

jmx[com.example:Type=Hello,weight]

Dans cet exemple, le nom de l'objet est "com.example:Type=Hello", le nom de l'attribut est "weight", et le type de valeur renvoyé devrait probablement être "Numérique (flottant)".

Attributs renvoyant des données composites

Cela devient plus compliqué lorsque votre attribut renvoie des données composites. Par exemple : votre nom d'attribut est "apple" et il renvoie un hachage représentant ses paramètres, comme "poids", "couleur", etc. Votre clé peut ressembler à ceci :

jmx[com.example:Type=Hello,apple.weight]

C'est ainsi qu'un nom d'attribut et une clé de hachage sont séparés, en utilisant le symbole point. De même, si un attribut renvoie des données composites imbriquées, les parties sont séparées par un point :

jmx[com.example:Type=Hello,fruits.apple.weight]

Attributs renvoyant des données tabulaires

Les attributs de données tabulaires consistent en un ou plusieurs attributs composites. Si un tel attribut est spécifié dans le paramètre de nom d'attribut, cette valeur d'élément renverra la structure complète de l'attribut au format JSON. Les valeurs d'élément individuelles à l'intérieur de l'attribut de données tabulaires peuvent être récupérées à l'aide du prétraitement.

Exemple d'attribut de données tabulaire :

 jmx[com.example:type=Hello,foodinfo]

Valeur de l'article :

[
  {
    "a": "apple",
    "b": "banana",
    "c": "cherry"
  },
  {
    "a": "potato",
    "b": "lettuce",
    "c": "onion"
  }
]

Problème avec les points

Jusqu’ici, tout va bien. Mais que faire si un nom d’attribut ou une clé de hachage contient un point ? Voici un exemple :

jmx[com.example:Type=Hello,all.fruits.apple.weight]

C’est un problème. Comment indiquer à Zabbix que le nom de l’attribut est "all.fruits", et pas seulement "all" ? Comment distinguer un point qui fait partie du nom d’un point qui sépare un nom d’attribut et des clés de hachage ?

C’est possible, il suffit d’échapper les points qui font partie du nom avec une barre oblique inverse :

jmx[com.example:Type=Hello,all\.fruits.apple.weight]

De la même manière, si votre clé de hachage contient un point, vous devez l’échapper :

jmx[com.example:Type=Hello,all\.fruits.apple.total\.weight]

Autres problèmes

Un caractère barre oblique inverse dans un nom d'attribut doit être échappé :

jmx[com.example:type=Hello,c:\\documents]

Pour la gestion de tout autre caractère spécial dans une clé d'élément JMX, veuillez consulter la section sur le format des clés d'élément section.

C'est en fait tout ce qu'il y a à savoir. Bonne surveillance JMX !

Types de données non primitifs

Il est possible de travailler avec des MBeans personnalisés renvoyant des types de données non primitifs, qui redéfinissent la méthode toString().

Utilisation d’un endpoint personnalisé avec JBoss EAP 6.4

Les endpoints personnalisés permettent de travailler avec différents protocoles de transport autres que le protocole RMI par défaut.

Pour illustrer cette possibilité, essayons de configurer la supervision de JBoss EAP 6.4 comme exemple. Commençons par poser quelques hypothèses :

Vous avez déjà installé Zabbix Java gateway. Sinon, vous pouvez le faire conformément à la documentation.
Zabbix server et Java gateway sont installés avec le préfixe /usr/local/
JBoss est déjà installé dans /opt/jboss-eap-6.4/ et fonctionne en mode autonome
Nous supposerons que tous ces composants fonctionnent sur le même hôte
Le pare-feu et SELinux sont désactivés (ou configurés en conséquence)

Appliquons quelques réglages simples dans zabbix_server.conf :

JavaGateway=127.0.0.1
StartJavaPollers=5

Et dans le fichier de configuration zabbix_java/settings.sh (ou zabbix_java_gateway.conf) :

START_POLLERS=5

Vérifiez que JBoss écoute sur son port de gestion standard :

$ netstat -natp | grep 9999
tcp        0      0 127.0.0.1:9999          0.0.0.0:*               LISTEN      10148/java

Créons maintenant un hôte avec l’interface JMX 127.0.0.1:9999 dans Zabbix.

Comme nous savons que cette version de JBoss utilise le protocole JBoss Remoting au lieu de RMI, nous pouvons mettre à jour en masse le paramètre d’endpoint JMX pour les éléments de notre modèle JMX en conséquence :

service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}

Mettons à jour le cache de configuration :

/usr/local/sbin/zabbix_server -R config_cache_reload

Notez que vous pouvez d’abord rencontrer une erreur.

« Unsupported protocol: remoting-jmx » signifie que Java gateway ne sait pas comment fonctionner avec le protocole spécifié. Cela peut être corrigé en créant un fichier ~/needed_modules.txt avec le contenu suivant :

jboss-as-remoting
jboss-logging
jboss-logmanager
jboss-marshalling
jboss-remoting
jboss-sasl
jcl-over-slf4j
jul-to-slf4j-stub
log4j-jboss-logmanager
remoting-jmx
slf4j-api
xnio-api
xnio-nio

puis en exécutant la commande :

for i in $(cat ~/needed_modules.txt); do find /opt/jboss-eap-6.4 -iname "${i}*.jar" -exec cp '{}' /usr/local/sbin/zabbix_java/lib/ \; ; done

Ainsi, Java gateway disposera de tous les modules nécessaires pour fonctionner avec jmx-remoting. Il ne reste plus qu’à redémarrer Java gateway, attendre un peu et, si vous avez tout fait correctement, constater que les données de supervision JMX commencent à arriver dans Zabbix (voir aussi : Données récentes).

What’s next?

14 Élément calculé

Docs

13 agent JMX

Aperçu