Quelqu’un at-il déjà eu un JMX JConsole à distance pour travailler?

Il semble que je n’ai jamais eu ce travail dans le passé. Actuellement, je sais que ça ne marche pas.

Mais nous démarrons notre processus Java:

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

Je peux faire un telnet vers le port et “quelque chose est là” (c’est-à-dire que si je ne commence pas le processus, rien ne répond, mais si c’est le cas), et port.

On dirait que ça devrait être si simple, mais pas d’erreurs, pas de bruit, rien. Juste ne fonctionne pas.

Quelqu’un connaît-il le conseil pour cela?

    J’ai une solution pour cela:

    Si votre processus Java s’exécute sous Linux derrière un parefeu et que vous souhaitez démarrer JConsole / Java VisualVM / Java Mission Control sous Windows sur votre ordinateur local pour le connecter au port JMX de votre processus Java .

    Vous devez avoir access à votre machine Linux via la connexion SSH. Toutes les communications seront effectuées par tunnel via la connexion SSH.

    ASTUCE: Cette solution fonctionne, peu importe si un pare-feu existe ou non.

    Inconvénient: Chaque fois que vous redémarrez votre processus java, vous devrez recommencer toutes les étapes du 4 au 9.

    1. Vous avez besoin de la suite de mastic pour votre machine Windows à partir d’ici:

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

    Au moins le putty.exe

    2. Définissez un port libre sur votre machine Linux:

      

    Exemple:

     jmx-remote-port = 15666 

    3. Ajouter des arguments au processus java sur la machine Linux

    Cela doit être fait exactement comme ça. Si c’est fait comme ci-dessous, cela fonctionne pour les machines Linux derrière les pare-feu (cela fonctionne à cause de l’argument -Djava.rmi.server.hostname=localhost ).

     -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.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 

    Exemple:

     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. Obtenez l’identifiant de processus de votre processus Java

     ps -ef | grep  result --->  

    Exemple:

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

    5. Rechercher un port arbitraire pour les stubs RMIServer

    Le processus java ouvre un nouveau port TCP sur la machine Linux, où les stubs serveur RMI seront disponibles pour téléchargement. Ce port doit également être disponible via SSH Tunnel pour obtenir une connexion à la machine virtuelle Java.

    Avec netstat -lp ce port peut aussi être trouvé, le lsof -i donne des indications sur le port ouvert du processus java.

    REMARQUE: Ce port change toujours lorsque le processus Java est démarré.

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

    Exemple:

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

    6. Activez deux tunnels SSH à partir de votre machine Windows avec du mastic

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

    Exemple:

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

    Paramètres pour ouvrir un tunnel SSL via Putty

    7. Connectez-vous à votre machine Linux avec Putty avec ce tunnel SSH activé.

    Laissez la session de mastic ouverte.

    Lorsque vous êtes connecté, Putty transfère toutes les connexions TCP à la machine Linux via le port SSH 22.

    JMX-Port:

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

    Port-serveur RMIServer:

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

    8. Démarrez JConsole / Java VisualVM / Java Mission Control pour vous connecter à votre processus Java à l’aide de l’URL suivante

    Cela fonctionne, car JConsole / Java VisualVM / Java Mission Control pense que vous vous connectez à un port sur votre machine Windows locale. mais Putty envoie toutes les données utiles au port 15666 à votre machine Linux.

    Sur la machine Linux, le processus Java répond en premier et renvoie le port du serveur RMIS. Dans cet exemple 37123.

    Puis JConsole / Java VisualVM / Java Mission Control pense se connecter à localhost: 37123 et putty enverront la totalité de la charge utile à la machine Linux

    Le processus Java répond et la connexion est ouverte.

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

    Exemple:

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

    Connectez-vous via l'URL du service jmx

    9. PROFITEZ # 8-]

    L’ajout de -Djava.rmi.server.hostname='' résolu ce problème pour moi.

    Essayé avec Java 8

    Cette solution fonctionne bien avec les pare-feu

    1. Ajoutez ceci à votre script de démarrage Java sur l’hôte distant:

     -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. Exécutez ceci sur votre ordinateur.

    • Utilisateurs Windows :

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

    • Utilisateurs Linux et Mac :

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

    3. Démarrez jconsole sur votre ordinateur

     jconsole localhost:1616 

    4. Amusez-vous!

    PS: à l’étape 2, vous utilisez ssh et -L pour spécifier que le port 1616 de l’hôte local (client) doit être transféré vers le côté distant. Ceci est un tunnel ssh et permet d’éviter les pare-feu ou les problèmes de réseaux divers.

    Vous rencontrez probablement un problème avec un pare-feu. Le problème est que le port que vous spécifiez n’est pas le seul port utilisé, il utilise 1 ou même 2 ports supplémentaires pour RMI, et ceux-ci sont probablement bloqués par un pare-feu.

    L’un des ports supplémentaires ne sera pas connu si vous utilisez la configuration RMI par défaut. Vous devez donc ouvrir une large gamme de ports, ce qui pourrait ne pas amuser l’administrateur du serveur.

    Il existe une solution qui ne nécessite pas d’ouvrir beaucoup de ports. Cependant, je l’ai fait fonctionner avec les extraits de code source et les astuces de

    http://forums.sun.com/thread.jspa?threadID=5267091 – le lien ne fonctionne plus

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

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

    Il est même possible de configurer un tunnel ssh et de le faire fonctionner 🙂

    Après avoir mis mon Google-fu à l’épreuve au cours des derniers jours, j’ai finalement réussi à le faire fonctionner après avoir compilé les réponses de Stack Overflow et de cette page http://help.boomi.com/atomsphere/GUID-F787998C- 53C8-4662-AA06-8B1D32F9D55B.html .

    Republier depuis la page 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 \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 seule ligne que je n’ai pas vu de couverture de réponse Stack Overflow est

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

    Dans mon cas, je tentais de récupérer les mésortingques Kakfa, j’ai donc simplement modifié l’option ci-dessus pour correspondre à la valeur -Dcom.sun.management.jmxremote.port . Donc, sans authentification d’aucune sorte, la configuration minimale doit ressembler à ceci:

     -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) 

    Est-ce que vous utilisez Linux? Peut-être que l’agent de gestion est lié à localhost:

    http://java.sun.com/j2se/1.5.0/docs/guide/management/faq.html#linux1

    Les étapes 4 à 7 de Sushicutta peuvent être ignorées en ajoutant la ligne suivante à l’étape 3:

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

    p.ex. Ajouter aux parameters de démarrage:

     -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 

    Pour le transfert de port, connectez en utilisant:

     ssh -L 12345:localhost:12345 @ 

    Si votre hôte est un tremplin, enchaînez simplement le port vers l’avant en exécutant ce qui suit sur le marchepied:

     ssh -L 12345:localhost:12345 @ 

    Rappelez-vous que le nom d’hôte = localhost est nécessaire pour vous assurer que jmxremote dit à la connexion rmi d’utiliser le tunnel. Sinon, il pourrait essayer de se connecter directement au pare-feu.

    PROTIP:

    Le port RMI est ouvert à des ports arbitraires. Si vous avez un pare-feu et que vous ne voulez pas ouvrir les ports 1024-65535 (ou utiliser vpn), vous devez procéder comme suit.

    Vous devez corriger (comme pour un numéro connu) les ports du registre RMI et du serveur JMX / RMI. Pour ce faire, placez un fichier jar (catalina-jmx-remote.jar dans les extensions) dans le répertoire lib et configurez un écouteur spécial sous le serveur:

      

    (Et bien sûr les drapeaux habituels pour activer JMX

      -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.ssl=false \ -Dcom.sun.management.jmxremote.authenticate=false \ -Djava.rmi.server.hostname= \ 

    Voir: JMX Remote Lifecycle Listener à l’ adresse http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

    Ensuite, vous pouvez vous connecter en utilisant cette URL horrible:

     service:jmx:rmi://:10002/jndi/rmi://:10001/jmxrmi 

    Vérifiez si votre serveur est derrière le pare-feu. JMX est basé sur RMI, qui ouvre deux ports au démarrage. L’un est le port de registre, la valeur par défaut est 1099 et peut être spécifiée par l’option com.sun.management.jmxremote.port . L’autre concerne la communication de données et est aléatoire, ce qui pose problème. Une bonne nouvelle est que, depuis JDK6, ce port aléatoire peut être spécifié par l’option 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" 

    Obtenir JMX via le pare-feu est vraiment difficile. Le problème est que RMI standard utilise un deuxième port assigné aléatoire (à côté du registre RMI).

    Nous avons trois solutions qui fonctionnent, mais chaque cas nécessite un autre:

    1. JMX over SSH Tunnel avec proxy Socks, utilise RMI standard avec SSH magic http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html

    2. JMX MP (alternative à RMI standard), utilise un seul port fixe, mais nécessite un jar spécial sur le serveur et le client http://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/

    3. Démarrez le code de formulaire du serveur JMX, il est possible d’utiliser RMI standard et d’utiliser un second port fixe: https://issues.apache.org/bugzilla/show_bug.cgi?id=39055

    Lorsque vous testez / déboguez / diagnostiquez des problèmes JMX distants , essayez d’abord de vous connecter sur le même hôte que celui contenant MBeanServer (localhost) pour éliminer les problèmes spécifiques au réseau et autres problèmes non liés à JMX.

    Il y a déjà de bonnes réponses ici, mais il y a une approche légèrement plus simple qui, à mon avis, mérite d’être partagée.

    L’approche de sushicutta est bonne, mais elle est très manuelle car vous devez obtenir le port RMI à chaque fois. Heureusement, nous pouvons contourner ce problème en utilisant un proxy SOCKS plutôt que d’ouvrir explicitement les tunnels de port. L’inconvénient de cette approche est que l’application JMX que vous exécutez sur votre machine doit pouvoir être configurée pour utiliser un proxy. La plupart des processus, vous pouvez le faire en ajoutant des propriétés Java, mais certaines applications ne le supportent pas.

    Pas:

    1. Ajoutez les options JMX au script de démarrage pour votre service Java distant:

       -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=8090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false 
    2. Configurez une connexion proxy SOCKS sur votre machine distante:

       ssh -D 9696 user@remotemachine.com 
    3. Configurez votre application de surveillance Java locale pour utiliser le proxy SOCKS (localhost: 9696). Note: Vous pouvez parfois le faire depuis la ligne de commande, à savoir:

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

    J’exécute JConsole / JVisualVm sur Windows en accrochant à Tomcat exécutant Linux Redhat ES3.

    Désactiver le filtrage de paquets à l’aide de la commande suivante a fait l’affaire:

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

    où jconsole-host est le nom d’hôte ou l’adresse d’hôte sur lequel JConsole s’exécute et où jmxremote-port est le numéro de port défini pour com.sun.management.jmxremote.port pour la gestion à distance.

    J’utilise boot2docker pour exécuter des conteneurs Docker avec Tomcat à l’intérieur et j’ai le même problème, la solution était de:

    • Ajouter -Djava.rmi.server.hostname=192.168.59.103
    • Utilisez le même port JMX dans l’hôte et le conteneur docker, par exemple: docker run ... -p 9999:9999 ... L’utilisation de différents ports ne fonctionne pas.

    Vous devez également vous assurer que le nom de votre ordinateur correspond à l’adresse IP à laquelle JMX est lié; PAS localhost ni 127.0.0.1. Pour moi, cela a aidé à mettre une entrée dans les hôtes qui la définit explicitement.

    Obtenir JMX via le pare-feu n’est pas si difficile. Il y a une petite prise. Vous devez transférer votre port configuré JMX, c.-à-d. 9010 et l’un des ports dynamics son écoute sur ma machine, il était> 30000

    Ce sont les étapes qui ont fonctionné pour moi (debian derrière le pare-feu du côté serveur, atteint via VPN à partir de mon Mac local):

    vérifier l’ip du serveur

     hostname -i 

    utilisez les parameters 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] 

    exécuter l’application

    trouver le pid du processus java en cours d’exécution

    vérifier tous les ports utilisés par JMX / RMI

     netstat -lp | grep [pid from step 4] 

    ouvrir tous les ports de l’étape 5 sur le pare-feu

    Voila.

    Pour faire une consortingbution, c’est ce que j’ai fait sur CentOS 6.4 pour Tomcat 6.

    1. Arrêt du service iptables

       service iptables stop 
    2. Ajoutez la ligne suivante à 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 cette façon, j’ai pu me connecter depuis un autre PC en utilisant JConsole.

    J’essaie de JMC pour exécuter l’enregistreur de vol (JFR) pour profiler NiFi sur un serveur distant qui ne propose pas d’environnement graphique sur lequel exécuter JMC.

    Sur la base des autres réponses données ici, et après beaucoup d’essais et d’erreurs, voici ce que je fournis à la JVM ( conf / bootstrap.conf ) lorsque je lance 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) 

    J’ai mis cela dans / etc / hosts , même si je doute que cela soit nécessaire:

     10.10.10.92 localhost 

    Puis, au lancement de JMC, je crée une connexion à distance avec ces propriétés:

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

    Incidemment, si je clique sur l’URL du service JMX personnalisé, je vois:

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

    Cela l’a finalement fait pour moi.