Il semble que je n'ai jamais réussi à faire fonctionner cela dans le passé. Actuellement, je sais que cela ne fonctionne 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 envoyer un telnet au port, et "quelque chose est là" (c'est-à-dire que si je ne lance pas le processus, rien ne répond, mais si je le fais, c'est le cas), mais je ne peux pas faire fonctionner JConsole en remplissant l'adresse IP et port.

On dirait que ça devrait être si simple, mais pas d'erreurs, pas de bruit, pas de rien. Ça ne marche pas.

Quelqu'un connaît-il le truc chaud pour ça?

J'ai une solution pour cela:

Si votre processus Java s'exécute sous Linux derrière un pare - feu et que vous souhaitez démarrer JConsole / Java VisualVM / Java Mission Control sur Windows sur votre machine locale pour le connecter au port JMX de votre processus Java .

Vous devez accéder à votre machine Linux via une connexion SSH. Toutes les communications seront acheminées via la connexion SSH.

CONSEIL: cette solution fonctionne, qu'il y ait un pare-feu ou non.

Inconvénient: chaque fois que vous redémarrez votre processus java, vous devrez recommencer toutes les étapes de 4 à 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:

<jmx-remote-port>

Exemple:

jmx-remote-port = 15666      

3. Ajoutez 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 des pare-feu (cela fonctionne à cause de l' -Djava.rmi.server.hostname=localhostargument).

-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

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 le Process-Id de votre processus Java

ps -ef | grep <java-processname>

result ---> <process-id>

Exemple:

ps -ef | grep ch.sushicutta.jmxremote.Main

result ---> 24321

5. Trouver un port arbitraire pour le téléchargement des stubs RMIServer

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

Avec netstat -lpce port, vous pouvez également trouver des lsof -iindications sur le port ouvert depuis le processus java.

REMARQUE: ce port change toujours lorsque le processus java est démarré.

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>

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

Exemple:

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

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

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

Laissez la session de mastic ouverte.

Lorsque vous êtes connecté, Putty tunnelise toutes les connexions TCP vers la machine Linux via le port SSH 22.

Port JMX:

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

RMIServer-Stub-Port:

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 toute la charge utile au port 15666 de votre machine Linux.

Sur la machine Linux, le processus java donne d'abord la réponse et renvoie le port RMIServer. Dans cet exemple 37123.

Ensuite, JConsole / Java VisualVM / Java Mission Control pense qu'il se connecte à localhost: 37123 et putty enverra 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:<jndi-remote-port>/jmxrmi

Exemple:

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

9. ENJOY # 8-]

L'ajout a -Djava.rmi.server.hostname='<host ip>'résolu ce problème pour moi.

Essayé avec Java 8 et les versions plus récentes

Cette solution fonctionne bien également 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 jconsolesur votre ordinateur

jconsole localhost:1616

4. Amusez-vous bien!

PS: à l'étape 2, à l'aide de sshet -Lvous spécifiez que le port 1616 de l'hôte local (client) doit être redirigé vers le côté distant. Il s'agit d'un tunnel ssh et permet d'éviter les pare-feu ou divers problèmes de réseau.

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 peut-être 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 à l'avance 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 en utilisant les extraits de code source combinés et les conseils 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 testé mon Google-fu ces derniers jours, j'ai finalement pu 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 .

Republication à partir de 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 <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 seule ligne pour laquelle je n'ai vu aucune couverture de réponse Stack Overflow est

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

Dans mon cas, j'essayais de récupérer les métriques Kakfa, j'ai donc simplement changé l'option ci-dessus pour qu'elle corresponde à la -Dcom.sun.management.jmxremote.portvaleur. Donc, sans authentification d'aucune sorte, la configuration minimale devrait 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)

Utilisez-vous 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=<same port as jmx-remote-port>

par exemple Ajouter aux paramètres 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 la redirection de port, connectez-vous en utilisant:

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

si votre hôte est un tremplin, enchaînez simplement le port en avant en exécutant ce qui suit sur la pierre de marche après ce qui précède:

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

N'oubliez pas que hostname = localhost est nécessaire pour s'assurer que jmxremote indique à la connexion rmi d'utiliser le tunnel. Sinon, il pourrait essayer de se connecter directement et toucher le pare-feu.

PROTIP:

Le port RMI est ouvert sur des portnr arbitraires. Si vous avez un pare-feu et que vous ne voulez pas ouvrir les ports 1024-65535 (ou utiliser vpn), vous devez faire ce qui suit.

Vous devez corriger (comme si vous aviez un numéro connu) les ports du registre RMI et du serveur JMX / RMI. Vous faites cela en mettant un fichier jar (catalina-jmx-remote.jar c'est dans les extra) dans le lib-dir et en configurant un écouteur spécial sous le serveur:

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

(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=<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://<hostname>:10002/jndi/rmi://<hostname>: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é par l' com.sun.management.jmxremote.portoption. L'autre est pour la communication de données, et est aléatoire, ce qui cause le problème. Une bonne nouvelle est que, à partir de JDK6, ce port aléatoire peut être spécifié par l' com.sun.management.jmxremote.rmi.portoption.

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"

Faire passer JMX à travers le pare-feu est vraiment difficile. Le problème est que RMI standard utilise un deuxième port assigné au hasard (à côté du registre RMI).

Nous avons trois solutions qui fonctionnent, mais chaque cas en nécessite une différente:

1. JMX sur 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 fichier 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 du formulaire JMX Server, là il est possible d'utiliser RMI standard et d'utiliser un deuxième port fixe: https://issues.apache.org/bugzilla/show_bug.cgi?id=39055

Lors du test / débogage / diagnostic des problèmes JMX distants , essayez d'abord de toujours vous connecter sur le même hôte qui contient le MBeanServer (c'est-à-dire localhost), pour écarter les problèmes de réseau et autres problèmes spécifiques non-JMX.

Il y a déjà de bonnes réponses ici, mais il existe une approche un peu plus simple que je pense qu'il vaut la peine de partager.

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 cela en utilisant un proxy SOCKS plutôt qu'en ouvrant explicitement les tunnels de port. L'inconvénient de cette approche est que l'application JMX que vous exécutez sur votre ordinateur doit pouvoir être configurée pour utiliser un proxy. La plupart des processus vous permettent de le faire en ajoutant des propriétés Java, mais certaines applications ne le prennent pas en charge.

Pas:

1. Ajoutez les options JMX au script de démarrage de 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 à votre machine distante:

   ssh -D 9696 [email protected]
   

3. Configurez votre application de surveillance Java locale pour utiliser le proxy SOCKS (localhost: 9696). Remarque: vous pouvez parfois le faire à partir de la ligne de commande, c'est-à-dire:

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

Ce qui suit a fonctionné pour moi (même si je pense que le port 2101 n'a pas vraiment contribué à cela):

-Dcom.sun.management.jmxremote.port=2100
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.rmi.port=2101
-Djava.rmi.server.hostname=<IP_ADDRESS>OR<HOSTNAME>

Je me connecte à partir d'une machine distante à un serveur sur lequel Docker est en cours d'exécution et le processus se trouve à l'intérieur du conteneur. De plus, j'ai arrêté firewallD mais je ne pense pas que ce soit le problème car je pouvais telnet à 2100 même avec le pare-feu ouvert. J'espère que ça aide.

J'exécute JConsole / JVisualVm sur Windows accroché à tomcat exécutant Linux Redhat ES3.

La désactivation du filtrage des paquets à l'aide de la commande suivante a fait l'affaire pour moi:

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

où jconsole-host est soit le nom d'hôte, soit l'adresse d'hôte sur laquelle JConsole s'exécute et 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 le conteneur hôte et 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 machine 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 définit explicitement cela.

Faire passer JMX à travers le pare-feu n'est pas du tout difficile. Il y a une petite capture. Vous devez rediriger à la fois votre port configuré JMX ie. 9010 et l'un des ports dynamiques qu'il écoute sur ma machine était> 30000

Voici les étapes qui ont fonctionné pour moi (debian derrière le pare-feu côté serveur, accessible via VPN depuis mon Mac local):

vérifier l'IP du serveur

hostname -i

utiliser les paramètres 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]

ouvrez tous les ports de l'étape 5 sur le pare-feu

Voila.

Afin d'apporter une contribution, c'est ce que j'ai fait sur CentOS 6.4 pour Tomcat 6.

1. Arrêter le 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 à partir d'un autre PC en utilisant JConsole.

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

Sur la base des autres réponses données ici, et après de nombreux essais et 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 ceci dans / etc / hosts , même si je doute que ce soit nécessaire:

10.10.10.92   localhost

Ensuite, 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.