Jolokia, una potente especia, para condimentar con Oracle Weblogic

Jolokia es uno de los chiles mas fuertes de planeta y también una utilidad para administrar Oracle Weblogic.

Jolokia es un puente JMX-HTTP que ofrece una alternativa a los conectores JSR-160. Es un enfoque basado en agentes con soporte para muchas plataformas. Además de las operaciones básicas de JMX, mejora la comunicación remota JMX con características exclusivas, como solicitudes masivas y políticas de seguridad detalladas.

Jolokia es un enfoque basado en agentes para el acceso remoto JMX. Es una alternativa a los conectores estándar JSR 160 (). La comunicación entre el cliente y el agente pasa por HTTP (GET o POST), donde la carga útil de solicitud y respuesta se representa en JSON.

El protocolo Jolokia admite las siguientes operaciones:

• Lectura y escritura de atributos JMX
• Ejecución de operaciones JMX
• Búsqueda de nombres MBean por patrón
• Listado de metadatos MBean como atributos, operaciones y notificaciones compatibles
• Hasta ahora las notificaciones JMX aún no son compatibles (pero están en la hoja de ruta para una versión futura).

La arquitectura general de Jolokia se muestra en el siguiente diagrama. El agente traduce entre JSON a través de HTTP y llamadas a MBeans locales, incluida una serialización JSON de los valores devueltos.

Este enfoque tiene algunas ventajas:

• Con la ayuda del agente, Jolokia puede proporcionar servicios que van más allá de la funcionalidad de los conectores JSR-160:

• Solicitudes masivas que permiten múltiples llamadas JMX en una sola solicitud
• Seguridad de grano fino con restricción de acceso en el funcionamiento de MBean y nivel de atributo.
• Fusión de múltiples MBeanServer en una vista virtual, por lo que no es necesario saber con antelación qué MBean está registrado en qué MBeanServer. Con JSR-160 el objetivo MBeanServer debe conocerse con anticipación.
• Modo de historial para almacenar valores recuperados previamente en un caché en el lado del servidor, junto con un sello de tiempo. Esto es especialmente útil para calcular el cambio de atributos JMX sin necesidad de un almacenamiento de cliente.
• No se requiere Java en el lado del cliente debido a la naturaleza neutral de plataforma de HTTP y JSON.
• La serialización JSON permite un acceso profundo a los objetos devueltos sin tener instaladas definiciones de tipos personalizados en el lado del cliente.
• Dado que HTTP usa un solo puerto predefinido, esta configuración funciona muy bien con la configuración del firewall. El conector predeterminado JSR-160, por el contrario, no es tan inteligente ya que RMI usa un puerto aleatorio para su comunicación por defecto.
• Por paradoja que pueda parecer, configurar un agente es a menudo más fácil que configurar la exportación JSR-160 JMX, especialmente cuando se trata de seguridad. Normalmente, para JSR-160, se deben adaptar los archivos de inicio de exportación y la configuración del servidor de aplicaciones. El agente estándar se implementa como una aplicación web normal, que es un procedimiento bien conocido.

La única desventaja de este modo es que se debe instalar un agente. Esto puede deberse a razones de política por la que no se permite instalar ninguna aplicación externa. O todos los servidores a monitorear ya están preparados para la exportación JSR-160 JMX, por lo que un paso de instalación adicional no es bienvenido. Además, actualizar Jolokia normalmente implica una redistribución del agente. 

Estas son todas buenas razones, por lo que Jolokia también tiene una respuesta. Al instalar un servidor JEE dedicado con un agente implementado, Jolokia puede operar en modo proxy, en cuyo caso traduce la solicitud de JOLOKIA JSON a la solicitud del cliente JSR-160 para la operación en el servidor de destino. Viceversa, el resultado sobre un conector JSR-160 luego se traduce en una respuesta JSON que se devuelve al cliente Jolokia.

Ejemplo

Para tener una idea de cómo es el protocolo de Jolokia, aquí hay un ejemplo de una simple solicitud y respuesta de Jolokia. Suponiendo que un agente está instalado, la siguiente solicitud HTTP GET lee las estadísticas de la memoria de montón utilizada de la JVM instrumentada:

 http://localhost:8080/jolokia/read/java.lang:type=Memory/HeapMemoryUsage

http: // localhost: 8080 / jolokia es la URL base bajo la cual se puede acceder al agente. La misma solicitud se puede realizar al enviar el siguiente cuerpo a la URL http: // localhost: 8080 / jolokia:

  {
    "mbean":"java.lang:type=Memory",
    "attribute":"HeapMemoryUsage",
    "type":"READ"
  }

En ambos casos, la respuesta contiene un objeto JSON:

 {
    "timestamp":1285531108,
    "status":200,
    "request": {
                 "mbean":"java.lang:type=Memory",
                 "attribute":"HeapMemoryUsage",
                 "type":"read"
               }, 
     "value": {
                "max":"129957888",
                "committed":"85000192",
                "init":"0",
                "used":"7713440"
              }
  }

Gestión RESTful de WebLogic con Jolokia

La administración y el monitoreo de los recursos de WebLogic es el pan de caa día para muchos administradores. La programación de una solución de gestión mediante la escritura de código JMX en Java es un proceso de bajo nivel y lento que puede evitarse utilizando la herramienta de scripts WebLogic basada en Jython (WLST).

WLST es un lenguaje de dominio específico de nivel superior (DSL) especialmente desarrollado para abordar problemas de gestión. Algunas líneas de código WLST suelen encapsular cientos de líneas de código Java utilizando JMX. Aunque WLST es compacto y fácil de escribir, aún adolece de la "J" en JMX: cada vez que ejecuta un script WLST para monitorear algún atributo en el servidor de aplicaciones, debe iniciarse una JVM en el lado del cliente para WLST. Esta sobrecarga puede ser bastante importante si está monitoreando muchos servidores y recuperando atributos a intervalos regulares. En particular, para sistemas de monitoreo como Nagios (o el Shinken más nuevo), el enfoque WLST no es adecuado.

Una de las nuevas características distintivas de WebLogic 12c es su servicio de administración RESTful, que se puede habilitar con un simple clic en DOMAIN / Configuration / General / Advanced / Enable RESTful Management Services  seguido de un reinicio del servidor.

Una vez habilitado, puede acceder a los valores de tiempo de ejecución de WebLogic 12c más importantes utilizando una sintaxis de URL simple de su navegador web o una herramienta de línea de comandos de Unix, como curl. Por ejemplo, puede recuperar datos de tiempo de ejecución del servidor de administración con una solicitud HTTP rápida en lugar de generar un proceso de JVM para WLST:

• http://localhost:7001/management/tenant-monitoring/servers/AdminServer/

Instalación

El proceso de instalación está bien descrito en el sitio de Jolokia. Simplemente puede obtener el archivo jolokia.war del sitio de descarga de Jolokia o el repositorio central de Maven, no se necesita nada más para WebLogic.

Incluso es posible usarlo sin ninguna implementación en absoluto. Comenzando con JDK6, puede ejecutarlo como un agente JVM, una técnica que se usa típicamente para los perfiladores, etc. Por lo tanto, su llamada java que inicia WebLogic tiene el siguiente formato:

java -javaagent:agent.jar ...

Si desea instalar todo el proyecto Jolokia (incluido el shell JMX que se describe más adelante, el complemento Nagios, un complemento Spring Roo, etc.) en un sistema UNIX con Perl y CPAN ya instalados, puede ser tan fácil como:

[root@ccloud ~]# perl -MCPAN -e shell cpan shell -- CPAN exploration and modules installation (v1.9800)

cpan[1]> install JMX:Jmx4Perl

[... you have to confirm the installation of several dependencies ...]

Comparación de funciones: Jolokia y WebLogic 12c RESTful Management Service

Ahora, ¿cómo se compara Jolokia con lo que ya tiene listo en la WebLogic 12c? Aquí hay una breve descripción:

La URL GET para una solicitud de lectura Jolokia tiene el siguiente formato:

&lt;base-url&gt;/read/&lt;<a title="MBean Object Name" href="http://docs.oracle.com/javase/6/docs/api/javax/management/ObjectName.html">mbean name</a>&gt;/&lt;attribute name&gt;/&lt;inner path&gt;

Para comenzar, simplemente pegue la siguiente URL en su navegador o use el curl de la utilidad de línea de comandos de Unix (suponiendo que tiene el servidor de administración ejecutándose en localhost: 7001). Recuperará los atributos configurados de ListenPort:

[JavaScript]

{ "request" : { "attribute" : "ListenPort",

      "mbean" : "com.bea:Type=Server,*",

      "type" : "read"

    },

  "status" : 200,

  "timestamp" : 1334776908,

  "value" : { "com.bea:Name=AdminServer,Type=Server" : { "ListenPort" : 7001 },

      "com.bea:Name=surf1,Type=Server" : { "ListenPort" : 7003 },

      "com.bea:Name=surf2,Type=Server" : { "ListenPort" : 7005 },

      "com.bea:Name=surf3,Type=Server" : { "ListenPort" : 7007 }

    }

}

[/JavaScript]

La respuesta se mostrará en una sola línea. Para obtener el formato anterior, puede pasar el resultado a uno de los muchos formateadores JSON en línea (o canalizar la salida curl a una utilidad adecuada).