¿cuál es la diferencia entre jolokia y jmxtrans? ¿Cuándo elegir uno sobre el otro?

Question

Estoy buscando una herramienta de consulta JMX. Me he encontrado con jolokia & jmxtrans, ambas soportan consultas basadas en JSON. JMXtrans tiene escritores para monitorear herramientas que creo que faltan en Jolokia. Busqué en Google, pero no obtuve mucha información comparando los dos. Pero he leído publicaciones positivas en el blog de ambas herramientas. Si alguien los ha usado antes, los pls comparten sus experiencias ...

Answer 1

Soy el autor de jmxtrans. Consideré Jolokia antes de desarrollar jmxtrans. Elijo desarrollar con jmxtrans porque tenía un uso diferente en mente.

Jolokia corre como una guerra en Tomcat. Es similar a jmxtrans en que le permite consultar un servidor JMX, pero ahí es donde termina la similitud. Debería implementar el resto de jmxtrans encima de Jolokia para tener paridad de características.

Por otro lado, jmxtrans es independiente sin requisitos en Tomcat. Mi público objetivo es el rol netops/devops. Está configurado con una estructura basada en JSON relativamente simple, por lo que no requiere un grado de ingeniería para configurarlo y usarlo.

La idea es que utilice jmxtrans para controlar continuamente los servicios que exponen estadísticas a través de jmx. Utiliza jmxtrans para 'transformar' datos de jmx al formato de salida que desee. En general, las personas devops quieren integrar sus JVM con algún tipo de solución de monitoreo como Graphite/Ganglia, así que proporcioné escritores de salida para esas herramientas.

jmxtrans también es muy inteligente acerca de cómo se realizan las consultas contra los servidores jmx y hay un poco de optimización para eso. También hay mucho trabajo que le permite hacer cosas como solicitudes paralelas a muchos servidores para permitirle escalar jmxtrans para consultar continuamente cientos de servidores con una sola instancia de jmxtrans.

Espero que aclare un poco las cosas. Si tiene preguntas específicas, me complace responderlas.

Answer 2

De hecho, jmxtrans y Jolokia tienen un enfoque diferente. Jmxtrans es una solución de monitoreo completa con un planificador que consulta las solicitudes JMX periódicamente y envía los resultados a un backend como graphite o rrdtool. Utiliza la comunicación estándar JSR-160 (basada en RMI) para consultar los servidores Java JMX

Jolokia por otro lado es un adaptador HTTP/JSON-JMX, que permite un acceso fácil para clientes que no son Java y agrega algunas características únicas que no están disponibles para una implementación pura de JSR-160. Para la integración en una plataforma de monitoreo, se necesita otra pieza de software. Para Nagios, hay Jmx4Perl que proporciona un complemento de Nagios completo para consultar a los agentes de Jolokia.

Como yo soy el autor Jolokia, déjame permito subrayar algunos aspectos destacados de Jolokia

• Muchas solicitudes se pueden enviar a la vez como una sola solicitudes en grandes cantidades. Esto permite consultar cientos de atributos con un solo giro de HTTP. Esto realmente hace una gran diferencia en entornos grandes.
• Debido al uso de HTTP Jolokia permite una fácil consulta a través de límites de firewall (que es una pesadilla cuando se utilizan conectores JMX estándar)
• autorización de grano fino es fácilmente posible mediante el uso de un archivo de política llanura XML
• Los agentes están disponibles no solo para Tomcat o cualquier otro contenedor Java EE, sino también para cualquier aplicación Java 6 (por ejemplo,ActiveMQ o Camel)
• Un buen conjunto de herramientas de líneas de comando (por ejemplo, un shell JMX basado en línea de lectura con finalización de comandos sensibles al contexto) viene con Jmx4Perl.
• Las bibliotecas de acceso de Perl, Javascript, Python, ... están disponibles.
• .... Para obtener más información, por favor refiérase a www.jolokia.org

En resumen, creo que se debe utilizar jmxtrans cuando se necesita una solución de monitoreo completo basado en JSR-160 comunicación remota (sin embargo, se puede usar Nagios y check_jmx4perl, también) y Jolokia cuando necesita superar las limitaciones de JSR-160 o puede beneficiarse de una de sus características únicas. Uno podría incluso imaginar integrar Jolokia en jmxtrans para la comunicación a los servidores para monitorear, que luego pasaría por JSON/HTTP en lugar de JSR-160 RMI (quizás esto también aclare el enfoque de diferencia y el caso de uso admitido).

Answer 3

que me puso un proyecto más en la mesa - https://github.com/dimovelev/metrics-sampler que las consultas de datos JMX el uso de expresiones regulares y la sustitución de variables y también soporta consultas JDBC como fuentes métricas (en su mayoría para monitorear nuestras estadísticas de base de datos Oracle) y mod_qos para la materia mod_qos Apache . Solo necesitamos grafito como salida y esa es la única salida que admite actualmente.

Por cierto, en mi humilde opinión, los puertos JMX son problemáticos con los firewalls solo porque el punto de conexión selecciona un puerto efímero aleatorio al inicio. Con jrockit se puede especificar (en el mismo puerto que el registro) con una opción jvm estándar. Para hacer esto en el punto de acceso, necesita codificarlo usted mismo (o reutilizar el código, por ejemplo, desde el conector tomcat jmx). Lo bueno es que está bien establecer ambos puertos con el mismo valor, por lo que solo necesitan una regla de firewall.

Saludos Dimo ​​