El monitoreo JMX se puede utilizar para monitorear los contadores JMX de un Java solicitud.
El monitoreo JMX tiene soporte nativo en Zabbix en forma de Zabbix demonio llamado "pasarela Zabbix Java".
Para recuperar el valor de un contador JMX particular en un host, Zabbix El servidor consulta la puerta de enlace Java de Zabbix, que a su vez utiliza el JMX gestión API para consultar la solicitud de interés de forma remota.
Para obtener más detalles y configuración, consulte Zabbix Java puerta de enlace.
::: nota de advertencia Comunicación entre la puerta de enlace Java y el monitorizado. La aplicación JMX no debe tener un firewall. :::
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 monitoreo JMX remoto.
Como mínimo, si sólo desea comenzar monitoreando una aplicación Java simple en un equipo local sin seguridad, comience 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 /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
Esto hace que Java escuche las conexiones JMX entrantes en el puerto 12345, desde el equipo local únicamente y le indica que no requiera autenticación ni SSL.
Si desea permitir conexiones en otra interfaz, configure el parámetro -Djava.rmi.server.hostname a la IP de esa interfaz.
Si desea ser más estricto con la seguridad, existen muchas otras opciones de Java disponibles para usted. Por ejemplo, el siguiente ejemplo inicia la aplicación con un conjunto más versátil de opciones y la abre a un público más amplio de red, 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=$TU_TIENDA_LLAVES \
-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 /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
La mayoría (si no todas) de estas configuraciones se pueden especificar en /etc/java-6-openjdk/management/management.properties
(o donde sea que el archivo este en su sistema).
Tenga en cuenta que si desea utilizar SSL, debe modificar el script startup.sh. agregando opciones -Djavax.net.ssl.*
a la puerta de enlace Java, para que sepa dónde encontrar las tiendas de claves y de confianza.
Consulte Monitoreo y gestión utilizando JMX para una descripción detallada.
Con la puerta de enlace de Java ejecutándose, el servidor sabe dónde encontrarla y una aplicación Java comenzó con soporte para monitoreo JMX remoto, es hora para configurar las interfaces y los elementos en Zabbix GUI.
Comienza creando una interfaz de tipo JMX en el host de interés.
Todos los campos de entrada obligatorios están marcados con un asterisco rojo.
Para cada contador JMX que le interese, agregue el elemento Agente JMX adjunto a esa interfaz.
La clave en la captura de pantalla a continuación dice jmx["java.lang:type=Memoria","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 elementos JMX son:
Tipo | Establezca agente JMX aquí. |
Clave | La clave del elemento jmx[] contiene tres parámetros:nombre de objeto: el nombre de objeto de un MBean nombre de atributo: un nombre de atributo de MBean con compuesto opcional nombres de campos de datos separados por puntos descripción breve única: una descripción única que permite múltiples elementos JMX con el mismo nombre de objeto y nombre de atributo en el host (opcional) Consulte a continuación para obtener más detalles sobre el elemento JMX claves. Puede descubrir MBeans y atributos de MBean utilizando un elemento jmx.discovery[] descubrimiento de bajo nivel. |
Punto final JMX | Puede especificar un punto final JMX personalizado. Asegúrese de que los parámetros de conexión del punto final JMX coincidan con la interfaz JMX. Esto se puede lograr utilizando macros {HOST.*} como se hace en el punto final JMX predeterminado. {HOST.*} macros y se admiten macros de usuario. |
Nombre de usuario | Especifique el nombre de usuario (hasta 255 caracteres), si ha configurado la autenticación en su aplicación Java. Se admiten macros de usuario. |
Contraseña | Especifique la contraseña (hasta 255 caracteres), si ha configurado la autenticación en su aplicación Java. Se admiten macros de usuario. |
Si desea monitorear un contador booleano que sea "verdadero" o "falso", luego especifica el tipo de información como "Numérica (sin firmar)" y seleccione el paso de preprocesamiento "Booleano a decimal" en Preprocesamiento pestaña. El servidor almacenará valores booleanos como 1 o 0, respectivamente.
El nombre de un objeto MBean no es más que una cadena que usted define en su Aplicación Java. Por otro lado, el nombre de un atributo puede ser más complejo. En caso de que un atributo devuelva un tipo de datos primitivo (un número entero, una cadena, etc.) no hay nada de qué preocuparse, la clave se verá así:
En este ejemplo, el nombre del objeto es "com.example:Type=Hello", el atributo del nombre es "peso", y el tipo de valor devuelto probablemente debería ser "Numérico (flotante)".
Se vuelve más complicado cuando su atributo devuelve datos compuestos. Por ejemplo: el nombre de su atributo es "manzana" y devuelve un hash representando sus parámetros, como "peso", "color", etc. Su clave puede se parece a esto:
Así es como se separan un nombre de atributo y una clave hash, utilizando un símbolo de punto De la misma manera, si un atributo devuelve datos compuestos anidados, el las partes están separadas por un punto:
Los atributos de datos tabulares constan de uno o varios atributos compuestos. Si dicho atributo se especifica en el parámetro de nombre de atributo, entonces este valor del elemento devolverá la estructura completa del atributo en formato JSON. Los valores de los elementos individuales dentro de los datos tabulares El atributo se puede recuperar mediante preprocesamiento.
Ejemplo de atributo de datos tabulares:
Valor del ítem:
[
{
"una manzana",
"b": "plátano",
"c": "cereza"
},
{
"una papa",
"b": "lechuga",
"c": "cebolla"
}
]
Hasta ahora, todo bien. Pero, ¿qué pasa si el nombre de un atributo o una clave hash contiene un punto? ¿símbolo? Aquí hay un ejemplo:
Eso es un problema. Cómo decirle a Zabbix que el nombre del atributo es ¿"todas las frutas", no sólo "todas"? Cómo distinguir un punto que forma parte de ¿El nombre del punto que separa el nombre de un atributo y las claves hash?
Esto es posible, todo lo que necesitas hacer es escapar de los puntos que forman parte de el nombre con una barra invertida:
De la misma manera, si tu clave hash contiene un punto, lo escapas:
Se debe utilizar como carácter de escape un carácter de barra invertida en el nombre de un atributo:
Para manejar cualquier otro carácter especial en la clave de elemento JMX, consulte la sección del formato de clave de la métrica.
En realidad, esto es todo lo que hay que hacer. ¡Feliz monitoreo JMX!
Es posible trabajar con MBeans personalizados que regresan tipos de datos no primitivos, que anulan el método toString().
Los puntos finales personalizados permiten trabajar con diferentes protocolos de transporte, otros que el RMI predeterminado.
Para ilustrar esta posibilidad, intentemos configurar JBoss EAP 6.4 seguimiento como ejemplo. Primero, hagamos algunas suposiciones:
/usr/local/
/opt/jboss-eap-6.4/
y se está ejecutando en modo independienteHagamos algunas configuraciones simples en zabbix_server.conf:
Y en el archivo de configuración zabbix_java/settings.sh
(o zabbix_java_gateway.conf
):
Verifique que JBoss escuche su puerto de administración estándar:
Ahora creemos un host con la interfaz JMX 127.0.0.1:9999 en Zabbix.
Como sabemos, esta versión de JBoss utiliza JBoss Remoting protocolo en lugar de RMI, podemos actualizar masivamente el parámetro del punto final JMX para los elementos de nuestra plantilla JMX en consecuencia:
Actualicemos el caché de configuración:
Tenga en cuenta que puede encontrar un error primero.
"Protocolo no compatible: remoting-jmx" significa que la puerta de enlace Java no saber trabajar con el protocolo especificado. Eso se puede arreglar con creando un archivo ~/needed_modules.txt
con el siguiente contenido:
jboss-como-remoto
registro de jboss
jboss-logmanager
jboss-marshalling
jboss-remoto
jboss-sasl
jcl-sobre-slf4j
julio-a-slf4j-stub
log4j-jboss-logmanager
comunicación remota-jmx
slf4j-api
xnio-api
xnio-nio
y luego ejecutando el comando:
para i en $(cat ~/needed_modules.txt); busque /opt/jboss-eap-6.4 -iname "${i}*.jar" -exec cp '{}' /usr/local/sbin/zabbix_java/lib/ \; ; hecho
Por lo tanto, la puerta de enlace Java tendrá todos los módulos necesarios para trabajar con jmx-remoto. Lo que queda es reiniciar el gateway Java, esperar un poco y Si hizo todo bien, verá que los datos de monitoreo de JMX comienzan a llegar a Zabbix (ver también: Datos más recientes).