Métodos para monitorizar remotamente Jboss EAP 6+/Wildfly 8+ con VisualVM

VisualVM (o JVisualVM si utilizamos la herramienta de la JDK) es una herramienta esencial tanto para realizar troubleshooting como para monitorizar los distintos componentes de nuestro servidor de aplicaciones.

Ofrece capacidades de monitorización de threads y generaciones de memoria, acceso/control de mbeans remotos y volcados de memoria/threads entre otros.

Monitor de heap, CPU, clases...

Monitor de heap, CPU, clases…

Visualización de threads

Visualización de threads

Monitorización avanzada de memoria con el plugin VisualGC

Monitorización avanzada de memoria con el plugin VisualGC

Para cumplir con su función la herramienta necesita asociarse (attach) a un determinado proceso Java. Teniendo en cuenta que en la mayor parte de las ocasiones el proceso Java estará siendo ejecutado en una máquina remota, podemos realizar la monitorización de tres formas:

  • Conectándonos a un demonio jstatd que se ejecutará en la máquina remota. Este demonio expone los procesos Java -actuando como proxy- de esa máquina para poder ser monitorizados externamente.
  • Conectándonos por JMX al servidor Jboss remoto. Requerirá configuración adicional en nuestro servidor de aplicaciones.
  • Exportando las X a nuestra máquina local y lanzando VisualVM/JVisualVM desde la máquina remota. La forma más sencilla.

Exponer procesos Java al exterior con jstatd

Ejecutar el demonio jstatd es una forma sencilla de acceder a todos los procesos Java que se encuentran en una máquina remota. Debemos tener en cuenta dos inconvenientes de este método:

  • Desde un punto de vista de la seguridad, utilizar jstatd expone todos nuestros procesos Java a conexiones externas sin necesidad de autenticación. Por lo tanto, si utilizamos jstatd debemos hacerlo de forma temporal o limitando los accesos a través de un firewall como iptables.
  • Podríamos considerar jstatd como un “proxy” entre nuestra máquina local y el proceso Java remoto que queremos monitorizar, pero nada más. Al no utilizar la API JMX no podremos beneficiarnos de las capacidades de esta como por ejemplo el acceso y operación sobre mbeans remotos.

Para configurar el acceso desde jstatd seguiremos estos pasos:

  1. Crear fichero jstatd.all.policy en el servidor remoto con el siguiente contenido. Cambiará según la versión de JDK que estés utilizando:
    grant codebase "file:/opt/java/jdk1.8.0_74/lib/tools.jar" {
            permission java.security.AllPermission;
    };
    

    En mi caso he creado el fichero en /opt/java/jstatd.all.policy

  2. Ejecutar jstatd en el servidor remoto especificando el puerto de escucha.
    /opt/java/jdk1.8.0_74/bin/jstatd -p 8888 -J-Djava.security.policy=/opt/java/jstatd.all.policy
    

    Si da problemas probar sin el prefijo -J (se supone que con a partir de la JDK 8 debería ser sin prefijo, aunque yo he tenido que añadirlo en algunas pruebas)

    /opt/java/jdk1.8.0_74/bin/jstatd -p 8888 -Djava.security.policy=/opt/java/jstatd.all.policy
    
  3. En nuestra máquina local, ejecutamos Visualvm/JVisualVM. Añadimos un host remoto (en mi caso 192.168.1.34) y después una conexión jstatd especificando el puerto de escucha remoto de jstatd:

Conexión JMX a servidor remoto

Si nuestro Jboss/Wildfly está en modo dominio, tendremos que añadir la línea remoting-connector use-management-endpoint=”false” en el subsistema JMX del perfil que estemos utilizando, por ejemplo el ha:

<profile name="ha">
...
    <subsystem xmlns="urn:jboss:domain:jmx:1.2">
         <expose-resolved-model/>
         <expose-expression-model/>
         <remoting-connector use-management-endpoint="false"/>
    </subsystem>
...
</profile>

Por defecto el punto de escucha JMX para una instancia de Jboss en modo dominio es el 4447. Si tenemos varias instancias entonces deberíamos sumar a este puerto el offset correspondiente.

Para modo standalone, no es necesario realizar ningún cambio en el servidor de aplicaciones.

Posteriormente crearemos una conexión JMX (en la imagen anterior de conexión jstatd podéis ver dónde realizarlo) en utilizando la siguiente cadena de conexión:

service:jmx:remoting-jmx://192.168.1.34:9999

Siendo 192.168.1.34 la IP remota y 9999 el mismo puerto de escucha de la CLI. Para autenticarnos, utilizaremos un usuario administrativo que tendremos que haber creado anteriormente con el script add-user de Jboss.

Exportando las X a nuestra máquina local

Este método considero que es el más sencillo, aunque necesitaremos un servidor X en nuestra máquina local. Si utilizamos Windows Xming puede ser una solución. Se pueden seguir las instrucciones que ya comenté en un artículo anterior.

Una vez tengamos las X exportadas a nuestra máquina local, en el servidor remoto ejecutaremos VisualVM o JVisualVM. El resultado es que al tener exportadas las X en local, podremos utilizar con total funcionalidad (acceso a capacidades JMX y Visual GC) la herramienta que en realidad se está ejecutando en el servidor remoto.