mbean ejemplo jmx jconsole

mbean - jmx ejemplo



¿Alguna vez alguien ha tenido una JMX JConsole remota para trabajar? (19)

Intento con Java 8

Esta solución funciona bien también con firewalls

1. Agregue esto a su script de inicio java en el host remoto:

-Dcom.sun.management.jmxremote.port=1616 -Dcom.sun.management.jmxremote.rmi.port=1616 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=false -Djava.rmi.server.hostname=localhost

2. Ejecuta esto en tu computadora.

  • Usuarios de Windows :

    putty.exe -ssh user@remote-host -L 1616:remote-host:1616

  • Usuarios de Linux y Mac :

    ssh user@remote-host -L 1616:remote-host:1616

3. Inicie jconsole en su computadora

jconsole localhost:1616

4. ¡Diviértete!

PD: durante el paso 2, al usar ssh y -L , especifica que el puerto 1616 en el host local (cliente) debe reenviarse al lado remoto. Este es un túnel ssh y ayuda a evitar firewalls o varios problemas de red.

Parece que nunca he conseguido que esto funcione en el pasado. Actualmente, SÉ que no funciona.

Pero comenzamos nuestro proceso de Java:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=6002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Puedo hacer telnet al puerto, y "algo está ahí" (es decir, si no comienzo el proceso, nada responde, pero si lo hago, lo hace), pero no puedo hacer que JConsole trabaje llenando el IP y puerto

Parece que debería ser tan simple, pero sin errores, sin ruido, sin nada. Simplemente no funciona.

Alguien sabe el punta caliente para esto?

Agregar -Djava.rmi.server.hostname=''<host ip>'' resolvió este problema para mí.

Al probar / depurar / diagnosticar problemas remotos de JMX, primero siempre intente conectarse en el mismo host que contiene el MBeanServer (es decir, el host local), para descartar la red y otros problemas no específicos de JMX.

Compruebe si su servidor está detrás del firewall. JMX está basado en RMI, que abre dos puertos cuando comienza. Uno es el puerto de registro, el valor predeterminado es 1099 y se puede especificar mediante la opción com.sun.management.jmxremote.port . El otro es para la comunicación de datos, y es aleatorio, que es lo que causa el problema. Una buena noticia es que, a partir de JDK6, este puerto aleatorio se puede especificar mediante la opción com.sun.management.jmxremote.rmi.port .

export CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8991 -Dcom.sun.management.jmxremote.rmi.port=8991 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

Después de poner mi Google-fu a prueba durante los últimos días, finalmente pude hacer que esto funcionara después de compilar las respuestas de y esta página http://help.boomi.com/atomsphere/GUID-F787998C-53C8-4662-AA06-8B1D32F9D55B.html .

Reposicionamiento de la página de Dell Boomi:

To Enable Remote JMX on an Atom If you want to monitor the status of an Atom, you need to turn on Remote JMX (Java Management Extensions) for the Atom. Use a text editor to open the <atom_installation_directory>/bin/atom.vmoptions file. Add the following lines to the file: -Dcom.sun.management.jmxremote.port=5002 -Dcom.sun.management.jmxremote.rmi.port=5002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

La única línea que no he visto ninguna cubierta de respuesta de es

-Dcom.sun.management.jmxremote.rmi.port=5002

En mi caso, estaba tratando de recuperar las métricas de Kakfa, así que simplemente cambié la opción anterior para que coincida con el valor -Dcom.sun.management.jmxremote.port . Por lo tanto, sin autenticación de ningún tipo, la configuración mínima debe ser así:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=(jmx remote port) -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.rmi.port=(jmx remote port) -Djava.rmi.server.hostname=(CNAME|IP Address)

Estos son los pasos que me funcionaron (debian detrás del firewall en el lado del servidor, alcanzado a través de VPN desde mi Mac local):

comprobar servidor ip

hostname -i

usa los parámetros de JVM:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=[jmx port] -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=[server ip from step 1]

ejecutar la aplicación

encontrar pid del proceso java en ejecución

verifique todos los puertos utilizados por JMX / RMI

netstat -lp | grep [pid from step 4]

abra todos los puertos desde el paso 5 en el firewall

Voila.

Estoy ejecutando JConsole / JVisualVm en Windows conectando a tomcat corriendo Linux Redhat ES3.

Desactivar el filtrado de paquetes usando el siguiente comando me funcionó:

/usr/sbin/iptables -I INPUT -s jconsole-host -p tcp --destination-port jmxremote-port -j ACCEPT

donde jconsole-host es el nombre de host o la dirección de host en la que JConsole se ejecuta y jmxremote-port es el número de puerto establecido para com.sun.management.jmxremote.port para la administración remota.

Estoy intentando que JMC ejecute el registrador de vuelo (JFR) para perfilar NiFi en un servidor remoto que no ofrece un entorno gráfico en el que ejecutar JMC.

En función de las otras respuestas dadas aquí, y de muchas pruebas y errores, esto es lo que estoy suministrando a la JVM ( conf / bootstrap.conf ) cuando ejecuto NiFi:

java.arg.90=-Dcom.sun.management.jmxremote=true java.arg.91=-Dcom.sun.management.jmxremote.port=9098 java.arg.92=-Dcom.sun.management.jmxremote.rmi.port=9098 java.arg.93=-Dcom.sun.management.jmxremote.authenticate=false java.arg.94=-Dcom.sun.management.jmxremote.ssl=false java.arg.95=-Dcom.sun.management.jmxremote.local.only=false java.arg.96=-Djava.rmi.server.hostname=10.10.10.92 (the IP address of my server running NiFi)

Puse esto en / etc / hosts , aunque dudo que sea necesario:

10.10.10.92 localhost

Luego, al iniciar JMC, creo una conexión remota con estas propiedades:

Host: 10.10.10.92 Port: 9098 User: (nothing) Password: (ibid)

A propósito, si hago clic en la URL del servicio JMX personalizado, veo:

service:jmx:rmi:///jndi/rmi://10.10.10.92:9098/jmxrmi

Esto finalmente lo hizo por mí.

Estoy usando boot2docker para ejecutar contenedores docker con Tomcat adentro y tengo el mismo problema, la solución fue:

  • Agregar -Djava.rmi.server.hostname=192.168.59.103
  • Utilice el mismo puerto JMX en el contenedor host y docker, por ejemplo: docker run ... -p 9999:9999 ... Usar diferentes puertos no funciona.

Los pasos 4-7 de Sushicutta se pueden omitir agregando la siguiente línea al paso 3:

-Dcom.sun.management.jmxremote.rmi.port=<same port as jmx-remote-port>

por ejemplo, agregar a los parámetros de inicio:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.rmi.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=false -Djava.rmi.server.hostname=localhost

Para el reenvío de puertos, conéctese usando:

ssh -L 12345:localhost:12345 <username>@<host>

Si su anfitrión es un trampolín, simplemente encastre el puerto hacia adelante ejecutando lo siguiente en el escalón después de lo anterior:

ssh -L 12345:localhost:12345 <username>@<host2>

Tenga en cuenta que el nombre de host = localhost es necesario para asegurarse de que jmxremote le está diciendo a la conexión rmi que use el túnel. De lo contrario, podría intentar conectarse directy y presionar el firewall.

Obtener JMX a través del Firewall es realmente difícil. El problema es que la RMI estándar usa un segundo puerto asignado aleatoriamente (al lado del registro RMI).

Tenemos tres soluciones que funcionan, pero cada caso necesita uno diferente:

  1. JMX sobre SSH Tunnel con proxy Socks, utiliza RMI estándar con magia SSH simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html

  2. JMX MP (alternativa a la RMI estándar), usa solo un puerto fijo, pero necesita una jar especial en el servidor y el cliente http://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/

  3. Inicie el código de formulario del servidor JMX, allí es posible usar el RMI estándar y usar un segundo puerto fijo: https://issues.apache.org/bugzilla/show_bug.cgi?id=39055

Obtener JMX a través del firewall no es tan difícil en absoluto. Hay una pequeña captura. Debe reenviar su puerto configurado JMX, es decir. 9010 y uno de los puertos dinámicos que escucha en mi máquina era> 30000

PROTIP:

El puerto RMI se abre en portnr arbitrarios. Si tiene un firewall y no quiere abrir los puertos 1024-65535 (o usa vpn), entonces necesita hacer lo siguiente.

Debe corregir (como tener un número conocido) los puertos del Registro RMI y del Servidor JMX / RMI. Para ello, coloque un archivo jar (catalina-jmx-remote.jar en el extra) en lib-dir y configure un detector especial en el servidor:

<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002" />

(Y por supuesto las banderas usuales para activar JMX

-Dcom.sun.management.jmxremote / -Dcom.sun.management.jmxremote.ssl=false / -Dcom.sun.management.jmxremote.authenticate=false / -Djava.rmi.server.hostname=<HOSTNAME> /

Ver: JMX Remote Lifecycle Listener en http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

Entonces puedes conectarte usando esta horrible URL:

service:jmx:rmi://<hostname>:10002/jndi/rmi://<hostname>:10001/jmxrmi

Para hacer una contribución, esto es lo que hice en CentOS 6.4 para Tomcat 6.

  1. Apagar el servicio de iptables

    service iptables stop

  2. Agregue la siguiente línea a tomcat6.conf

    CATALINA_OPTS="${CATALINA_OPTS} -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8085 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=[host_ip]"

De esta forma pude conectarme desde otra PC usando JConsole.

Probablemente estés experimentando un problema con un firewall. El "problema" es que el puerto que especifique no es el único utilizado, utiliza 1 o tal vez 2 puertos más para RMI, y probablemente estén bloqueados por un firewall.

Uno de los puertos adicionales no se conocerá de antemano si usa la configuración de RMI predeterminada, por lo que debe abrir una gran variedad de puertos, lo que podría no divertir al administrador del servidor.

Hay una solución que no requiere abrir muchos puertos, sin embargo, he logrado que funcione con los fragmentos de código fuente combinados y consejos de

http://forums.sun.com/thread.jspa?threadID=5267091 - el enlace ya no funciona

http://blogs.oracle.com/jmxetc/entry/connecting_through_firewall_using_jmx

http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html

Incluso es posible configurar un túnel ssh y hacer que funcione :-)

También debe asegurarse de que el nombre de su máquina resuelva la IP a la que JMX se está vinculando; NO localhost ni 127.0.0.1. Para mí, ha ayudado a poner una entrada en los hosts que explícitamente define esto.

Tengo una solución para esto:

Si su proceso Java se ejecuta en Linux detrás de un firewall y desea iniciar JConsole / Java VisualVM / Java Mission Control en Windows en su máquina local para conectarlo al puerto JMX de su proceso Java .

Necesita acceder a su máquina Linux a través del inicio de sesión SSH. Todas las comunicaciones se canalizarán a través de la conexión SSH.

CONSEJO: Esta solución funciona sin importar si hay un firewall o no.

Desventaja: cada vez que reinicie su proceso Java, deberá realizar todos los pasos del 4 al 9 nuevamente.


1. Necesitas la masilla para tu máquina con Windows desde aquí:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Al menos putty.exe


2. Defina un puerto libre en su máquina Linux:

<jmx-remote-port>

Ejemplo:

jmx-remote-port = 15666


3. Agregue argumentos al proceso de Java en la máquina de Linux

Esto debe hacerse exactamente así. Si se hace como a continuación, funciona para las máquinas Linux detrás de los cortafuegos (Funciona a causa de -Djava.rmi.server.hostname=localhost argumento -Djava.rmi.server.hostname=localhost ).

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=<jmx-remote-port> -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=false -Djava.rmi.server.hostname=localhost

Ejemplo:

java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=15666 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=false -Djava.rmi.server.hostname=localhost ch.sushicutta.jmxremote.Main


4. Obtiene ID de proceso de tu proceso Java

ps -ef | grep <java-processname> result ---> <process-id>

Ejemplo:

ps -ef | grep ch.sushicutta.jmxremote.Main result ---> 24321


5. Encontrar el puerto arbitrario para los resbalones de RMIServer descargar

El proceso java abre un nuevo Puerto TCP en la máquina Linux, donde los Trozos de servidor RMI estarán disponibles para su descarga. Este puerto también debe estar disponible a través del Túnel SSH para conectarse a la Máquina Virtual Java.

Con netstat -lp este puerto se puede encontrar también el lsof -i da pistas sobre qué puerto se ha abierto desde el proceso java.

NOTA: Este puerto siempre cambia cuando se inicia el proceso de java.

netstat -lp | grep <process-id> tcp 0 0 *:<jmx-remote-port> *:* LISTEN 24321/java tcp 0 0 *:<rmi-server-port> *:* LISTEN 24321/java result ---> <rmi-server-port>

Ejemplo:

netstat -lp | grep 24321 tcp 0 0 *:15666 *:* LISTEN 24321/java tcp 0 0 *:37123 *:* LISTEN 24321/java result ---> 37123


6. Habilite dos SSH-Túneles desde su máquina con masilla de Windows

Source port: <jmx-remote-port> Destination: localhost:<jmx-remote-port> [x] Local [x] Auto Source port: <rmi-server-port> Destination: localhost:<rmi-server-port> [x] Local [x] Auto

Ejemplo:

Source port: 15666 Destination: localhost:15666 [x] Local [x] Auto Source port: 37123 Destination: localhost:37123 [x] Local [x] Auto



7. Inicie sesión en su máquina Linux con Putty con este SSH-Tunnel habilitado.

Deje la sesión de masilla abierta.

Cuando haya iniciado sesión, la masilla canalizará todas las conexiones TCP a la máquina de linux sobre el puerto SSH 22.

JMX-Port:

Windows machine: localhost:15666 >>> SSH >>> linux machine: localhost:15666

RMIServer-Stub-Port:

Windows Machine: localhost:37123 >>> SSH >>> linux machine: localhost:37123


8. Inicie JConsole / Java VisualVM / Java Mission Control para conectarse a su Proceso Java utilizando la siguiente URL

Esto funciona, porque JConsole / Java VisualVM / Java Mission Control cree que se conecta a un puerto en su máquina local de Windows. pero Putty envía toda la carga útil al puerto 15666 a su máquina Linux.

En la máquina de Linux, primero el proceso de Java da respuesta y devuelve el puerto de RMIServer. En este ejemplo 37123.

Entonces JConsole / Java VisualVM / Java Mission Control cree que se conecta a localhost: 37123 y putty enviará toda la carga útil hacia la máquina de linux

El proceso de Java responde y la conexión está abierta.

[x] Remote Process: service:jmx:rmi:///jndi/rmi://localhost:<jndi-remote-port>/jmxrmi

Ejemplo:

[x] Remote Process: service:jmx:rmi:///jndi/rmi://localhost:15666/jmxrmi



9. DISFRUTA # 8-]

Ya hay algunas buenas respuestas aquí, pero hay un enfoque un poco más simple que creo que vale la pena compartir.

El enfoque de sushicutta es bueno, pero es muy manual ya que debes obtener el puerto RMI cada vez. Afortunadamente, podemos solucionarlo utilizando un proxy SOCKS en lugar de abrir explícitamente los túneles del puerto. La desventaja de este enfoque es que la aplicación JMX que ejecuta en su máquina necesita poder configurarse para usar un Proxy. La mayoría de los procesos puede hacer esto al agregar propiedades de Java, pero algunas aplicaciones no son compatibles.

Pasos:

  1. Agregue las opciones de JMX al script de inicio para su servicio Java remoto:

    -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=8090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

  2. Configure una conexión proxy SOCKS a su máquina remota:

    ssh -D 9696 [email protected]

  3. Configure su aplicación de monitoreo local de Java para usar el proxy SOCKS (localhost: 9696). Nota: a veces puede hacer esto desde la línea de comando, es decir:

    jconsole -J-DsocksProxyHost=localhost -J-DsocksProxyPort=9696