agente 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 host de interés.

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

Añadir item de agent JMX

Para cada contador JMX que le interese, añada un item de JMX agent vinculado a esa interfaz.

La clave en la captura de pantalla siguiente es jmx["java.lang:type=Memory","HeapMemoryUsage.used"].

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

Los campos que requieren información específica para los items JMX son:

Si desea supervisar un contador Boolean que sea "true" o "false", especifique el tipo de información como "Numeric (unsigned)" y seleccione el paso de preprocesamiento "Boolean to decimal" en la pestaña Preprocessing. Server almacenará los valores Boolean 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 escaparse:

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

Para manejar cualquier otro carácter especial en la clave del item JMX, consulte la sección sobre el formato de la clave del item section.

En realidad, eso es todo. ¡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 distintos protocolos de transporte además del RMI predeterminado.

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.
• Zabbix server 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 host
• 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 administració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 host con interfaz JMX 127.0.0.1:9999 en Zabbix.

Como sabemos que esta versión de JBoss usa el protocolo JBoss Remoting en lugar de RMI, podemos actualizar masivamente el parámetro del endpoint JMX para los items de nuestra template JMX en consecuencia:

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 primero puede encontrarse con un error.

"Unsupported protocol: remoting-jmx" significa que Java gateway no sabe cómo trabajar con el protocolo especificado. Esto se puede corregir 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. Solo queda reiniciar Java gateway, esperar un poco y, si ha hecho todo correctamente, verá que los datos de monitorización JMX comienzan a llegar a Zabbix (consulte también: Latest data).