web-dev-qa-db-fra.com

Comment activer JMX sur ma machine virtuelle pour un accès avec jconsole?

Comment activer JMX sur une machine virtuelle pour un accès avec jconsole?

javajvmmonitoringjmxjconsole
184
Mauli

La documentation pertinente peut être trouvée ici:

http://Java.Sun.com/javase/6/docs/technotes/guides/management/agent.html

Démarrez votre programme avec les paramètres suivants:

-Dcom.Sun.management.jmxremote
-Dcom.Sun.management.jmxremote.port=9010
-Dcom.Sun.management.jmxremote.local.only=false
-Dcom.Sun.management.jmxremote.authenticate=false
-Dcom.Sun.management.jmxremote.ssl=false

Par exemple, comme ceci:

Java -Dcom.Sun.management.jmxremote \
  -Dcom.Sun.management.jmxremote.port=9010 \
  -Dcom.Sun.management.jmxremote.local.only=false \
  -Dcom.Sun.management.jmxremote.authenticate=false \
  -Dcom.Sun.management.jmxremote.ssl=false \
  -jar Notepad.jar

-Dcom.Sun.management.jmxremote.local.only=false n'est pas nécessairement requis mais sans cela, cela ne fonctionnerait pas sur Ubuntu. L'erreur serait quelque chose comme Ceci:

01 Oct 2008 2:16:22 PM Sun.rmi.transport. customer .TCPTransport$AcceptLoop executeAcceptLoop
WARNING: RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=37278] throws
Java.io.IOException: The server sockets created using the LocalRMIServerSocketFactory only accept connections from clients running on the Host where the RMI remote objects have been exported.
    at Sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.Java:89)
    at Sun.rmi.transport. customer .TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.Java:387)
    at Sun.rmi.transport. customer .TCPTransport$AcceptLoop.run(TCPTransport.Java:359)
    at Java.lang.Thread.run(Thread.Java:636)

voir http://bugs.Sun.com/bugdatabase/view_bug.do?bug_id=6754672

Faites également attention avec -Dcom.Sun.management.jmxremote.authenticate=false, ce qui rend l'accès accessible à tout le monde, mais si vous ne l'utilisez que pour suivre la JVM sur Votre machine locale, cela n'a pas d'importance.

Mettre à jour:

Dans certains cas, je n'ai pas pu atteindre le serveur. Ceci a ensuite été corrigé si je définissais également ce paramètre: -Djava.rmi.server.hostname=127.0.0.1

251
Mauli

Courir dans un conteneur Docker a introduit toute une série de problèmes supplémentaires pour la connexion, alors espérons que cela aidera quelqu'un. J'ai fini par avoir besoin d'ajouter les options suivantes que j'expliquerai ci-dessous:

-Dcom.Sun.management.jmxremote=true
-Dcom.Sun.management.jmxremote.local.only=false
-Dcom.Sun.management.jmxremote.authenticate=false
-Dcom.Sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=${DOCKER_Host_IP}
-Dcom.Sun.management.jmxremote.port=9999
-Dcom.Sun.management.jmxremote.rmi.port=9998

DOCKER_Host_IP

Contrairement à l'utilisation locale de jconsole, vous devez publier une adresse IP différente de celle que vous verrez probablement dans le conteneur. Vous devrez remplacer ${DOCKER_Host_IP} par l'adresse IP (nom DNS) pouvant être résolue en externe de votre hôte Docker.

Ports JMI et RMI

Il semble que JMX nécessite également l'accès à une interface de gestion à distance ( jstat ) qui utilise un autre port pour transférer des données lors de l'arbitrage de la connexion. Je n'ai rien vu de suite dans jconsole pour définir cette valeur. Dans l'article lié, le processus était le suivant:

  • Essayez de vous connecter à partir de jconsole avec la journalisation activée
  • Fail
  • Déterminez quel port jconsole a tenté d'utiliser
  • Utilisez les règles iptables/firewall si nécessaire pour permettre à ce port de se connecter

Bien que cela fonctionne, ce n'est certainement pas une solution automatisable. J'ai opté pour une mise à niveau de jconsole vers VisualVM car cela vous permet de spécifier explicitement le port sur lequel jstatd est en cours d'exécution. Dans VisualVM, ajoutez un nouvel hôte distant et mettez-le à jour avec les valeurs corrélées à celles spécifiées ci-dessus:

Add Remote Host

Cliquez ensuite avec le bouton droit sur la nouvelle connexion à l'hôte distant et sur Add JMX Connection....

Add JMX Connection

N'oubliez pas de cocher la case Do not require SSL connection. Espérons que cela devrait vous permettre de vous connecter.

41
Joel B

Remarque: Java 6 dans la dernière incarnation permet à jconsole de se connecter à un processus en cours, même après son démarrage sans incantations JMX.

Si cela vous est disponible, pensez également à jvisualvm car il fournit une mine d’informations sur les processus en cours, y compris un profileur.

9
Thorbjørn Ravn Andersen

J'utilise WAS ND 7.0

Ma machine virtuelle Java a besoin de surveiller tous les arguments suivants dans JConsole

    -Djavax.management.builder.initial= 
    -Dcom.Sun.management.jmxremote 
    -Dcom.Sun.management.jmxremote.port=8855 
    -Dcom.Sun.management.jmxremote.authenticate=false 
    -Dcom.Sun.management.jmxremote.ssl=false
7
user3013578

Sous Linux, j'ai utilisé les paramètres suivants:

-Djavax.management.builder.initial= 
-Dcom.Sun.management.jmxremote 
-Dcom.Sun.management.jmxremote.port=9010 
-Dcom.Sun.management.jmxremote.local.only=false
-Dcom.Sun.management.jmxremote.authenticate=false 
-Dcom.Sun.management.jmxremote.ssl=false

et aussi j'ai édité /etc/hosts pour que le nom d'hôte soit résolu en adresse d'hôte (192.168.0.x) plutôt qu'en adresse de bouclage (127.0.0.1)

6
alex.pulver

avec les paramètres de ligne de commande ci-dessous, 

-Dcom.Sun.management.jmxremote.port=9999
-Dcom.Sun.management.jmxremote.authenticate=false
-Dcom.Sun.management.jmxremote.ssl=false

Parfois, dans les serveurs linux, la connexion imx ne réussit pas. c'est parce que, dans l'hôte cloud linux, dans/etc/hosts afin que le nom d'hôte soit résolu en adresse d'hôte. 

le meilleur moyen de résoudre ce problème est d’envoyer une requête ping au serveur Linux concerné à partir d’une autre machine du réseau et d’utiliser cette adresse IP hôte dans le répertoire. 

-Djava.rmi.server.hostname=IP address that obtained when you ping that linux server.

Mais ne vous fiez jamais à l'adresse IP que vous obtenez du serveur Linux en utilisant ifconfig.me. l'adresse IP que vous obtenez est masquée par celle qui est présente dans le fichier hôte.

3
Phani Kumar

Exécutez votre application Java avec les paramètres de ligne de commande suivants:

-Dcom.Sun.management.jmxremote.port=8855
-Dcom.Sun.management.jmxremote.authenticate=false
-Dcom.Sun.management.jmxremote.ssl=false

Il est important d'utiliser le paramètre -Dcom.Sun.management.jmxremote.ssl = false si vous ne souhaitez pas configurer de certificats numériques sur l'hôte jmx. 

Si vous avez démarré votre application sur un ordinateur dont l'adresse IP est 192.168.0.1, ouvrez jconsole , put 192.168.0.1:8855 dans le champ Remote Process et cliquez sur Relier.

2
Wasif

J'ai eu ce problème, et créé un projet GitHub pour tester et déterminer les paramètres corrects .

Il contient une Dockerfile de travail avec des scripts de prise en charge et un simple docker-compose.yml pour un test rapide.

0
cstroe

Vous devez d’abord vérifier si votre processus Java est déjà en cours d’exécution avec les paramètres JMX. Faire ceci: 

ps -ef | grep Java

Vérifiez votre processus Java que vous devez surveiller. Si vous pouvez voir le paramètre jmx rmi Djmx.rmi.registry.port = xxxx , utilisez le port mentionné ici dans votre visualvm Java pour le connecter à distance via une connexion jmx. 

Si cela ne fonctionne pas via le port jmx rmi, vous devez exécuter votre processus Java avec les paramètres mentionnés ci-dessous:

-Djmx.rmi.registry.port=1234 -Djmx.rmi.port=1235 -Dcom.Sun.management.jmxremote.authenticate=false -Dcom.Sun.management.jmxremote.ssl=false

Remarque: les numéros de port sont basés sur votre choix.

Vous pouvez maintenant utiliser ce port pour la connexion jmx. Ici c'est le port 1234.

0
Abhay S