13 Monitorización JMX

Descripción general

La monitorización JMX puede utilizarse para monitorizar contadores JMX de una aplicación Java.

La monitorización JMX tiene soporte nativo en Zabbix en forma de un demonio de Zabbix llamado "Java gateway de Zabbix".

Para recuperar el valor de un contador JMX particular en un equipo, el servidor Zabbix consulta al Java gateway de Zabbix, que a su vez utiliza la API de gestión JMX para consultar la aplicación de interés de forma remota.

Para más detalles y configuración, consulte la sección Java gateway de Zabbix.

Habilitar la monitorización remota JMX para una aplicación Java

Una aplicación Java no necesita ningún software adicional instalado, pero debe iniciarse con las opciones de línea de comandos especificadas a continuación para tener soporte para la monitorización remota JMX.

Como mínimo, si solo desea comenzar monitorizando una aplicación Java simple en un equipo local sin seguridad aplicada, iníciela con estas opciones:

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 /ruta/a/su/aplicacion.jar

Esto hace que Java escuche conexiones JMX entrantes en el puerto 12345, solo desde el equipo local, y le indica que no requiera autenticación ni SSL.

Si desea permitir conexiones en otra interfaz, establezca el parámetro -Djava.rmi.server.hostname en la IP de esa interfaz.

Si desea ser más estricto con la seguridad, hay muchas otras opciones de Java disponibles para usted. Por ejemplo, el siguiente ejemplo inicia la aplicación con un conjunto de opciones más versátil y la abre a una red más amplia, no solo al equipo 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 /ruta/a/su/aplicacion.jar

La mayoría (si no todas) de estas configuraciones pueden especificarse en $JRE/lib/management/management.properties (o dondequiera que se encuentre ese archivo en su sistema).

Tenga en cuenta que si desea usar SSL, debe modificar el script startup.sh agregando las opciones -Djavax.net.ssl.* al Java gateway, para que sepa dónde encontrar los almacenes de claves y de confianza.

Consulte Monitorización y gestión usando JMX para una descripción detallada.

Configuración de interfaces y métricas JMX en el frontend de Zabbix

Con el Java gateway en ejecución, el servidor sabiendo dónde encontrarlo y una aplicación Java iniciada con soporte para la monitorización remota de JMX, es momento de configurar las interfaces y métricas en la interfaz gráfica de Zabbix.

Configuración de la interfaz JMX

Comience creando una interfaz de tipo JMX en el equipo de interés.

Todos los campos obligatorios están marcados con un asterisco rojo.

Añadir una métrica de agente JMX

Para cada contador JMX que le interese, añada una métrica de agente JMX asociada a esa interfaz.

La clave en la captura de pantalla a continuación indica jmx["java.lang:type=Memory","HeapMemoryUsage.used"].

Todos los campos obligatorios están marcados con un asterisco rojo.

Los campos que requieren información específica para las métricas JMX son:

Si desea monitorizar un contador Booleano que sea "true" o "false", entonces debe especificar el tipo de información como "Numérico (sin signo)" y seleccionar el paso de preprocesamiento "Booleano a decimal" en la pestaña Preprocesamiento. El servidor almacenará los valores Booleanos como 1 o 0, respectivamente.

Claves de métricas JMX en detalle

Atributos simples

Un nombre de objeto MBean no es más que una cadena que usted define en su aplicación Java. Un nombre de atributo, por otro lado, puede ser más complejo. En caso de que un atributo devuelva un tipo de dato primitivo (un entero, una cadena, etc.), no hay de qué preocuparse, la clave se verá así:

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

En este ejemplo, el nombre del objeto es "com.example:Type=Hello", el nombre del atributo es "weight", y el tipo de valor devuelto probablemente debería ser "Numérico (flotante)".

Atributos que devuelven datos compuestos

Se vuelve más complicado cuando su atributo devuelve datos compuestos. Por ejemplo: el nombre de su atributo es "apple" y devuelve un hash que representa sus parámetros, como "weight", "color", etc. Su clave podría verse así:

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

Así es como se separan el nombre del atributo y la clave del hash, utilizando un punto. De la misma manera, si un atributo devuelve datos compuestos anidados, las partes se separan por un punto:

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

Atributos que devuelven datos tabulares

Los atributos de datos tabulares consisten en uno o varios atributos compuestos. Si dicho atributo se especifica en el parámetro de nombre de atributo, entonces el valor de esta métrica devolverá la estructura completa del atributo en formato JSON. Los valores de los elementos individuales dentro del atributo de datos tabulares pueden recuperarse utilizando preprocesamiento.

Ejemplo de atributo de datos tabulares:

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

Valor de la métrica:

[
         {
           "a": "manzana",
           "b": "plátano",
           "c": "cereza"
         },
         {
           "a": "patata",
           "b": "lechuga",
           "c": "cebolla"
         }
       ]

Problema con los puntos

Hasta aquí todo bien. Pero, ¿qué pasa si un nombre de atributo o una clave de hash contiene el símbolo de punto? Aquí tienes un ejemplo:

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

Eso es un problema. ¿Cómo decirle a Zabbix que el nombre del atributo es "all.fruits", y no solo "all"? ¿Cómo distinguir un punto que forma parte del nombre de un punto que separa un nombre de atributo y claves de hash?

Esto es posible, todo lo que necesitas hacer es escapar los puntos que forman parte del nombre con una barra invertida:

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

De la misma manera, si tu clave de hash contiene un punto, escápalo:

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

Otros problemas

Un carácter de barra invertida en un nombre de atributo debe ser escapado:

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

Para manejar cualquier otro carácter especial en la clave de la métrica JMX, consulte la sección sobre el formato de la clave de la métrica sección.

Esto es realmente todo lo que hay que saber. ¡Feliz monitorización JMX!

Tipos de datos no primitivos

Es posible trabajar con MBeans personalizados que devuelven tipos de datos no primitivos, que sobrescriben el método toString().

Uso de un endpoint personalizado con JBoss EAP 6.4

Los endpoints personalizados permiten trabajar con diferentes protocolos de transporte además del RMI por defecto.

Para ilustrar esta posibilidad, intentemos configurar la monitorización de JBoss EAP 6.4 como ejemplo. Primero, hagamos algunas suposiciones:

• Ya ha instalado Zabbix Java gateway. Si no es así, puede hacerlo de acuerdo con la documentación.
• El servidor Zabbix y Java gateway están instalados con el prefijo /usr/local/
• JBoss ya está instalado en /opt/jboss-eap-6.4/ y se está ejecutando en modo standalone
• Supondremos que todos estos componentes funcionan en el mismo equipo
• El firewall y SELinux están deshabilitados (o configurados en consecuencia)

Hagamos algunos ajustes simples en zabbix_server.conf:

JavaGateway=127.0.0.1
       StartJavaPollers=5

Y en el archivo de configuración zabbix_java/settings.sh (o zabbix_java_gateway.conf):

START_POLLERS=5

Compruebe que JBoss escucha en su puerto de gestión estándar:

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

Ahora vamos a crear un equipo con interfaz JMX 127.0.0.1:9999 en Zabbix.

Como sabemos que esta versión de JBoss utiliza el protocolo JBoss Remoting en lugar de RMI, podemos actualizar masivamente el parámetro endpoint JMX para las métricas en nuestra plantilla JMX de la siguiente manera:

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

Actualicemos la caché de configuración:

/usr/local/sbin/zabbix_server -R config_cache_reload

Tenga en cuenta que puede encontrar un error al principio.

"Unsupported protocol: remoting-jmx" significa que Java gateway no sabe cómo trabajar con el protocolo especificado. Esto se puede solucionar creando un archivo ~/needed_modules.txt con el siguiente contenido:

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

y luego ejecutando el comando:

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

De este modo, Java gateway tendrá todos los módulos necesarios para trabajar con jmx-remoting. Lo que queda es reiniciar Java gateway, esperar un poco y, si hizo todo correctamente, verá que los datos de monitorización JMX comienzan a llegar a Zabbix (ver también: Últimos datos).