Quelqu'un a-t-il déjà fait fonctionner une JConsole JMX à distance?


120

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?


3
Si vous utilisez tomcat, cela peut être la solution: stackoverflow.com/questions/1263991/…
Hajo Thelen

5
Avez-vous oublié d'accepter quelque chose ici @Will?
Gris

Réponses:


126

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


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


Connectez-vous via l'URL du service jmx


9. ENJOY # 8-]


1
Juste une petite question ici - pas possible de faire une connexion JMX sans rmi?
Kumar Vaibhav

5
J'ai eu un indice, que nous pouvons définir un rmi.port sur un numéro de port fixe, afin que nous puissions définir le port arbitraire pour le téléchargement des stubs RMIServer. cela devrait fonctionner avec la propriété Java "com.sun.management.jmxremote.rmi.port = <rmi-server-port>". Cela ressemble à une fonctionnalité non documentée dans Oracle Java VM.
sushicutta

1
Bien sûr, il vaut mieux configurer des keystores et des magasins de confiance
TekiusFanatikus

Même processus, mais je n'ai pas d'objet de ce type dans le tableau
wener

2
@sushicutta pouvez-vous ajouter cet indice dans votre réponse, cela fonctionne parfaitement bien et peut supprimer les étapes de 4 à 6, le hic est que votre port transféré doit être le même que le port d'origine et que les ports jmx et rmi doivent également être le même
minable

80

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


2
Dans mon cas, je dois ajouter une adresse IP (-Djava.rmi.server.hostname = <ip>). hostname -i m'a donné deux adresses IP et la bonne était la deuxième dans la liste.
Georgy Bolyuba

4
n'a pas résolu le problème pour moi. connecter windows-2-windows n'est pas un problème pour moi MAIS lorsque j'essaie de me connecter à partir d'une JVM Jvisualvm.exe sous Windows pour surveiller un service java fonctionnant sur SUSE avec Oracle JDK 1.6.024, la connexion échoue. Pour cette raison, je pense que cette question sur les personnes reste sans réponse.
djangofan

Cela a résolu le problème pour moi. Ceci plus l'ensemble habituel de 3 (authentifier / port / ssl) et je peux me connecter à distance maintenant. La boîte écoute sur plusieurs interfaces virtuelles cependant, peut-être pourquoi ne pas spécifier l'hôte a confondu le jvm.
Nicholi

J'ai finalement résolu mes problèmes de connexion de jconsole sur mon ordinateur portable osx. Merci.
rado

A travaillé pour moi. Je vous remercie!
Jeff

58

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.


1
IMPRESSIONNANT!! J'essaye depuis plus de 6 heures maintenant de jmx-remote vers une instance ActiveMQ sur java8. ENFIN QUELQUE CHOSE QUI A FONCTIONNÉ !! Merci! :)
Rop

Merci, comme vous, j'ai lutté pendant environ un jour aussi, et après tant de travail, j'ai juste pensé: "Je dois écrire ce truc à SO !!"
Freedev

2
Vraiment nul qu'Oracle ne mentionne "com.sun.management.jmxremote.rmi.port", "java.rmi.server.hostname" docs.oracle.com/javase/8/docs/technotes/guides/management/… I suppose que c'était mon problème.
Rop

Parce que, AFAIK, ce problème ne concerne pas JMX, mais comment RMI fonctionne. Par exemple, après ce cas, j'ai eu le même problème avec jmeter, qui utilise rmi dans son implémentation client / serveur.
freeev

2
Ça marche. Juste en ajoutant mon expérience avec les tunnels: 1) peut utiliser "localhost" dans "-L 1616: localhost: 1616" 2) ne peut pas changer le port source, c'est-à-dire que cela ne fonctionnera pas: "-L 9999: localhost: 1616"
gargii

19

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


2
J'ai pu contourner le pare-feu en utilisant uniquement l'alias décrit dans simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html avec le réglage -Djava.rmi.server.hostname comme mentionné dans une autre réponse ici.
Damien

Note aux futurs lecteurs: le lien vers forums.sun.comest rompu
CDspace

1
Note aux futurs lecteurs: le lien vers blogs.oracle.comest rompu.
Grimlock

17

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)

1
Plus un pour "Google-fu"
kevinarpe

"com.sun.management.jmxremote.rmi.port" était également la clé pour moi. Voir aussi cette réponse: stackoverflow.com/a/22306586/123205
David

Je n'avais pas besoin de "com.sun.management.jmxremote.local.only" donc je ne pense pas que votre configuration soit vraiment "strict minimum"
David


7

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.


Cette méthode m'aide: (1) J'ajoute des paramètres JMX manqués et redémarre l'application (2 ssh -L <JMX_port>:localhost:<JMX_port> <remote_user>@<remote_host> ) Puis je l' exécute sur une machine locale (3) Puis je me connecte à JMX distant en utilisant: jconsole <remote_host>:<JMX_port>
Rib47

6

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

J'ai essayé ce qui précède avec le jar des extras, et je peux voir les ports RMI à l'écoute comme spécifié, mais les ports aléatoires sont toujours utilisés par RMI après la connexion au port JVM avec VisualVM. Solution: surveillez les ports avec «lsof -i» et ouvrez ceux dont les connexions sont bloquées.
Joseph Lust

5

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"

4

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


Toutes les autres réponses devraient être un ajout à celle-ci
ruruskyi

2

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.


2

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 user@remotemachine.com
    
  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
    

2

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.


1

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.


2
n'a pas fonctionné pour moi sur une instance SUSE Amazon EC2. je pense que le problème se situe ailleurs.
djangofan

1

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.

0

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.


0

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


0

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.


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.