java - mbean - jmx monitoring
¿Es una buena idea habilitar jmx(sonda lambda) en un servidor de producción? (5)
Estamos experimentando algunas desaceleraciones en nuestra aplicación web implementada en un Tomcat 5.5.17 que se ejecuta en Sun VM 1.5.0_06-b05 y nuestra empresa de alojamiento no brinda suficientes datos para encontrar el problema.
Estamos considerando instalar la sonda lambda en el servidor de producción, pero se requiere habilitar JMX (com.sun.management.jmxremote) para obtener estadísticas de memoria y CPU.
¿Permitir JMX incurrir en una grave penalización de rendimiento?
Si habilitamos JMX, ¿estamos abriendo algún defecto de seguridad? ¿Debo configurar la autenticación segura si solo estamos habilitando el acceso local a JMX?
¿Alguien está usando lo mismo (sonda tomcat + lambda) sin problemas en la producción?
ACTUALIZAR
En cuanto a las respuestas, parece que habilitar JMX solo no implica una sobrecarga significativa para la máquina virtual. El trabajo adicional puede venir si la aplicación de monitoreo conectada a la VM, ya sea JConsole , sonda lambda o cualquier otra, está sondeando con excesiva dedicación.
JMX es solo un socket que espera conexiones y permite que los procesos externos accedan a los datos que se recopilan de todos modos. La penalización suele ser muy baja (a menos que martillees el servidor JMX con solicitudes, por supuesto).
JMX le permite llegar a las entrañas de su VM Java. Hay comandos para ejecutar un GC y apagarlo. Dicho esto, JMX ofrece un modo de conexión segura que utiliza claves públicas y autenticación. Por favor, lea los documentos para más detalles.
Puede tachar los fallos de seguridad mediante la autenticación segura. Solo mantener el servicio JMX listo no implica ninguna sobrecarga significativa y generalmente es una buena idea. Aquí hay un punto de referencia sobre esto.
depende de la implementación de JMX y de qué tan caro es el material que desea supervisar. Ahora tengo al menos una aplicación JMX, que tiene una sobrecarga de memoria relativamente alta.
Estamos utilizando la sonda lambda en servidores de producción y no vimos ningún gasto significativo. Puedo recomendar probe como producto confiable listo para producción usando (Tomcats 5.5 y 6.0, JDK 5 y JDK 6).
La sobrecarga de JMX es baja y puede reparar la seguridad mediante SSL y autenticación. Set -Dcom.sun.management.jmxremote.ssl = true y -Dcom.sun.management.jmxremote.authenticate = true
Consulte aquí para obtener más información sobre la configuración de certificados, etc.
La sobrecarga se convierte en un problema cuando comienzas a instrumentar el código. La sobrecarga puede ser sustancial y la instrumentación puede afectar el comportamiento de su aplicación. No verás lo que obtienes, el llamado efecto Heisenberg .
Si quieres una sobrecarga baja, usaría las herramientas que vienen con JRockit . Se apoyan en la información que la JVM recopila todo el tiempo. La JVM mantiene estadísticas de qué métodos son los más utilizados para decidir qué métodos debe optimizar. La JVM también realiza un seguimiento del uso / patrones de memoria para decidir qué estrategia de gc seleccionar. JRockit expone esos datos amables a las herramientas JRockit sin agregar la sobrecarga de instrumentación que normalmente obtendrías de un agente JMVTI independiente.