j'ai une solution pour ça:

si votre processus Java tourne sur Linux derrière un pare-feu et que vous voulez 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 avez besoin d'accéder à votre machine linux via un login SSH. Toutes les Communications seront acheminés sur le Connexion SSH.

astuce: Cette Solution fonctionne peu importe s'il y a un pare-feu ou non.

désavantage: Everytime you redémarrez votre processus java, vous aurez besoin de faire toutes les étapes à partir de 4 - 9 à nouveau.

1. Vous avez besoin de la putty-suite pour votre machine Windows d'ici:

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

au moins le mastic.exe

2. Définissez un Port libre sur votre machine linux:

<jmx-remote-port>

exemple:

jmx-remote-port = 15666      

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

cela doit être fait exactement comme ceci. Si son fait comme ci-dessous, il fonctionne pour les Machines linux derrière les pare-feu (il fonctionne cause de l'argument -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

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 de l'Id du Processus de votre Processus Java

ps -ef | grep <java-processname>

result ---> <process-id>

exemple:

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

result ---> 24321

5. Trouver le Port arbitraire pour le téléchargement de stubs RMIServer

le processus java ouvre un nouveau Port TCP sur la machine linux, où le serveur RMI-Stubs sera disponible pour le téléchargement. Ce port doit également être disponible via le Tunnel SSH pour obtenir une connexion à la Machine virtuelle Java.

avec netstat -lp ce port se trouve aussi le lsof -i donne des indications sur le port qui a été ouvert depuis le processus java.

NOTE: ce port change toujours lorsque le processus java est lancé.

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. Permettre deux Tunnels SSH de votre machine Windows avec putty

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 le mastic session ouverte.

lorsque vous êtes connecté, Putty va tunnel toutes les connexions TCP vers la machine linux sur le port 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. Démarrer JConsole / Java VisualVM / Java Mission Control pour vous connecter à votre processus Java en utilisant 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 envoyer toute la charge utile au port 15666 à 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.

puis JConsole / Java VisualVM / Java Mission Control pense qu'il se connecte à localhost: 37123 et putty enverra toute la charge utile vers 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 -]

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

essayé avec Java 8

Cette solution fonctionne aussi bien avec les pare-feu

1. Ajoutez ceci à votre script de démarrage java sur remote-host:

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

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

• utilisateurs de Linux et Mac :

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

3. Démarrer jconsole sur votre ordinateur

jconsole localhost:1616

4. Amusez-vous!

P.S.: pendant l'étape 2, en utilisant ssh et -L , vous spécifiez que le port 1616 sur l'hôte local (client) doit être redirigé vers le côté distant. Il s'agit d'un tunnel ssh qui 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 y a une solution qui n'a pas besoin d'ouvrir beaucoup de ports cependant, je l'ai fait fonctionner en utilisant les extraits de source combinés et des 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 mis mon google-fu à l'essai pour les derniers jours, j'ai enfin été en mesure d'obtenir ce à travailler après la compilation des réponses de la pile Overflow et cette page http://help.boomi.com/atomsphere/GUID-F787998C-53C8-4662-AA06-8B1D32F9D55B.html .

reprise 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 que je n'ai pas vu de couverture de réponse de dépassement de pile est

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

dans mon cas, je tentais de récupérer les mesures de Kakfa, donc j'ai simplement changé l'option ci-dessus pour correspondre à la valeur -Dcom.sun.management.jmxremote.port . Ainsi, 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)

êtes-vous sous Linux? Peut-être l'agent de gestion lie-t-il localhost:

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

les étapes 4-7 de Sushicutta peuvent être sautées en ajoutant la ligne suivante à l'étape 3:

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

p.ex. 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 le transfert 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 le Step stone après le ci-dessus:

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

l'Esprit que le hostname=localhost est nécessaire pour s'assurer que le jmxremote dit à la connexion rmi d'utiliser le tunnel. Sinon, il pourrait essayer de connecter directy et de frapper le pare-feu.

PROTIP:

les ports RMI sont ouverts à des ports arbitraires. Si vous avez un pare-feu et que vous ne voulez pas ouvrir les ports 1024-65535 (ou utiliser vpn), alors vous devez faire ce qui suit.

vous devez corriger (comme si vous aviez un numéro connu) le Registre RMI et les ports de serveur JMX/RMI. Vous faites cela en mettant un pot-de fichier (catalina-jmx à distance.jar il est dans le supplément) dans le lib-dir et la configuration d'un auditeur 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 distant Lifecycle Listener à http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

alors 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. Le premier est le port de Registre, la valeur par défaut est 1099, et peut être spécifié par l'option com.sun.management.jmxremote.port . L'autre est pour la communication de données, et est aléatoire, qui est ce qui cause problème. Une bonne nouvelle est que, à partir de 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 à travers le pare-feu est vraiment difficile. Le problème est que le RMI standard utilise un second port aléatoire assigné (à côté du RMI registry).

nous avons trois solutions qui fonctionnent, mais chaque cas a besoin d'une différente:

1. JMX via le Tunnel SSH avec proxy Socks, utilise la norme de RMI avec SSH magie http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html

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

3. Start JMX Server Code de forme, il est possible d'utiliser RMI standard et utiliser un port fixe de deuxième: https://issues.apache.org/bugzilla/show_bug.cgi?id=39055

lors de l'essai/débogage/diagnostic problèmes "remote JMX, d'abord toujours essayer de se connecter sur le même hôte qui contient le MBeanServer (c.-à-d. localhost), pour exclure le réseau et d'autres problèmes spécifiques non-JMX.

il y a déjà de grandes réponses ici, mais il y a 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 de chaussettes plutôt qu'en ouvrant explicitement les tunnels du port. L'inconvénient de cette approche est que l'application JMX que vous utilisez sur votre machine doit pouvoir être configurée pour utiliser un Proxy. La plupart des processus vous peut faire cela en ajoutant des propriétés java, mais, certaines applications ne prennent pas en charge cela.

Suit:

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. configurer une connexion proxy SOCKS à votre machine distante:

   ssh -D 9696 user@remotemachine.com
   

3. configurez votre application locale de surveillance Java pour utiliser le proxy de SOCKS (localhost:9696). Note: vous pouvez parfois faire cela à partir de la ligne de commande, i.e.:

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

j'exécute JConsole/JVisualVm sur windows accrochant à tomcat exécutant Linux Redhat ES3.

désactiver le filtrage de paquets en utilisant 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 de l'hôte sur laquelle JConsole s'exécute et jmxremote-port est le numéro de port défini pour com.soleil.gestion.jmxremote.port pour 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
• utiliser le même port JMX dans le conteneur hôte et docker, par exemple: docker run ... -p 9999:9999 ... . Utiliser différents ports ne fonctionne pas.

vous devez également vous assurer que votre nom de machine se résout à L'adresse IP à laquelle JMX est lié; pas localhost ni 127.0.0.1. Pour moi, il a aidé à mettre une entrée dans les hôtes qui définit explicitement.

obtenir JMX à travers le pare-feu n'est pas si difficile que ça. Il y a un petit hic. Vous devez transmettre à la fois votre port JMX configuré ie. 9010 et un de ses ports dynamiques é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 par VPN depuis mon Mac local):

check ip du serveur

hostname -i

utilisation de la JVM params:

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

le tour est joué.

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

1. Shutdown iptables service

   service iptables stop
   

2. ajouter 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]"
   

ainsi j'ai pu me connecter à partir d'un autre PC en utilisant JConsole.

j'essaye à 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.

basé sur les autres réponses données ici, et sur beaucoup d'essais et d'erreurs, voici ce que je fournis à la JVM ( conf/bootstrap.conf ) quand 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 , bien que je doute qu'il soit nécessaire:

10.10.10.92   localhost

ensuite, lors du 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 personnalisé JMX, je vois:

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

cela a finalement fait pour moi.