Connexion JMX distante

J’essaie d’ouvrir une connexion JMX à une application Java s’exécutant sur une machine distante.

L’application JVM est configurée avec les options suivantes:

  • com.sun.management.jmxremote
  • com.sun.management.jmxremote.port = 1088
  • com.sun.management.jmxremote.authenticate = false
  • com.sun.management.jmxremote.ssl = false

Je peux me connecter en utilisant localhost:1088 utilisant jconsole ou jvisualvm. Mais je ne peux pas me connecter en utilisant xxx.xxx.xxx.xxx:1088 depuis une machine distante.

Il n’y a pas de pare-feu entre les serveurs ou sur le système d’exploitation. Mais pour éliminer cette possibilité, je fais telnet xxx.xxx.xxx.xxx 1088 et je pense qu’il se connecte, car l’écran de la console devient vide.

Les deux serveurs sont Windows Server 2008 x64. Essayé avec JVM 64 bits et 32 ​​bits, ni travail.

Si cela avait été sous Linux, le problème serait que localhost est l’interface de bouclage , il faut que l’application se lie à l’ interface réseau .

Vous pouvez utiliser le netstat pour confirmer qu’il n’est pas lié à l’interface réseau attendue.

Vous pouvez faire cela en appelant le programme avec le paramètre système java.rmi.server.hostname="YOUR_IP" , soit en tant que variable d’environnement, soit en utilisant

 java -Djava.rmi.server.hostname=YOUR_IP YOUR_APP 

J’ai passé plus d’une journée à essayer de faire fonctionner JMX depuis l’extérieur de localhost. Il semble que SUN / Oracle n’ait pas réussi à fournir une bonne documentation à ce sujet.

Assurez-vous que la commande suivante vous renvoie une véritable IP ou HOSTNAME. S’il renvoie quelque chose comme 127.0.0.1, 127.0.1.1 ou localhost, cela ne fonctionnera pas et vous devrez mettre à jour le fichier /etc/hosts .

 hostname -i 

Voici la commande nécessaire pour activer JMX même de l’extérieur

 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=1100 -Djava.rmi.server.hostname=myserver.example.com 

Comme vous l’avez supposé, myserver.example.com doit correspondre à ce que renvoie hostname -i .

De toute évidence, vous devez être sûr que le pare-feu ne vous bloque pas, mais je suis presque sûr que ce n’est pas votre problème, le problème étant le dernier paramètre non documenté.

Lors de mes tests avec Tomcat et Java 8, la JVM ouvrait un port éphémère en plus de celui spécifié pour JMX. Le code suivant m’a réparé; Essayez-le si vous rencontrez des problèmes lorsque votre client JMX (par exemple, VisualVM ne se connecte pas).

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

Voir aussi Pourquoi Java ouvre 3 ports lorsque JMX est configuré?

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

Si vous essayez d’accéder à un serveur qui se trouve derrière un NAT, vous devrez probablement démarrer votre serveur avec l’option

 -Djava.rmi.server.hostname= 

de sorte que les stubs RMI envoyés au client contiennent l’adresse publique du serveur, ce qui permet aux clients de les atteindre de l’extérieur.

il semblerait que votre citation finale arrive trop tôt. Il devrait être après le dernier paramètre.

Ce truc a fonctionné pour moi.

J’ai remarqué quelque chose d’intéressant: quand je lance mon application en utilisant la ligne de commande suivante:

 java -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false 

Si j’essaie de me connecter à ce port depuis un ordinateur distant à l’aide de jconsole, la connexion TCP aboutit, certaines données sont échangées entre jconsole distant et l’agent jmx local où mon MBean est déployé. Jconsole affiche ensuite un message d’erreur de connexion. J’ai effectué une capture de restreinte, et cela montre l’échange de données provenant de l’agent et de jconsole.

Donc, ce n’est pas un problème de réseau, si j’effectue un netstat -an avec ou sans propriété système java.rmi.server.hostname, j’ai les liaisons suivantes:

  TCP 0.0.0.0:9999 0.0.0.0:0 LISTENING TCP [::]:9999 [::]:0 LISTENING 

Cela signifie que dans les deux cas, le socket créé sur le port 9999 accepte les connexions de n’importe quel hôte sur n’importe quelle adresse.

Je pense que le contenu de cette propriété système est utilisé quelque part lors de la connexion et comparé à l’adresse IP réelle utilisée par l’agent pour communiquer avec jconsole. Et si ces adresses ne correspondent pas, la connexion échoue.

Je n’ai pas eu ce problème lors de la connexion à partir du même hôte en utilisant jconsole, uniquement à partir de véritables hôtes distants physiques. Donc, je suppose que cette vérification est effectuée uniquement lorsque la connexion vient de “l’extérieur”.

Merci beaucoup, ça marche comme ça:

java -Djava.rmi.server.hostname = xxx.xxx.xxx.xxx -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl = false -Dcom.sun.management.jmxremote.authenticate = false – Dcom.sun.management.jmxremote.port = 25000 -jar myjar .jar

La chose qui a fonctionné pour moi a été de définir / etc / hosts pour pointer le nom d’hôte vers l’IP et non vers l’interface de bouclage et de redémarrer mon application.

cat / etc / hosts

 127.0.0.1 localhost.localdomain localhost 192.168.0.1 myservername 

Ceci est ma configuration:

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

J’ai le même problème et je change tout nom d’hôte qui correspond au nom d’hôte local en 0.0.0.0, cela semble fonctionner après cela.

Pour activer la télécommande JMX, passez les parameters de la machine virtuelle avec JAVA Command.

  -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=453 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=myDomain.in 

Essayez d’utiliser des ports supérieurs à 3000.