Hat jemand jemals eine Remote-JMX-JConsole zum Laufen gebracht?


120

Es scheint, dass ich das in der Vergangenheit nie zum Laufen gebracht habe. Derzeit weiß ich, dass es nicht funktioniert.

Aber wir starten unseren Java-Prozess:

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

Ich kann mit dem Port telneten und "etwas ist da" (das heißt, wenn ich den Prozess nicht starte, antwortet nichts, aber wenn ich es tue, tut es das), aber ich kann JConsole nicht dazu bringen, die IP auszufüllen und Hafen.

Scheint so einfach zu sein, aber keine Fehler, kein Rauschen, kein Nichts. Funktioniert einfach nicht.

Kennt jemand den heißen Tipp dafür?


3
Wenn Sie Tomcat verwenden, ist dies möglicherweise die Lösung: stackoverflow.com/questions/1263991/…
Hajo Thelen

5
Hast du vergessen, hier @Will etwas anzunehmen?
Grau

Antworten:


126

Ich habe eine Lösung dafür:

Wenn Ihr Java-Prozess unter Linux hinter einer Firewall ausgeführt wird und Sie JConsole / Java VisualVM / Java Mission Control unter Windows auf Ihrem lokalen Computer starten möchten , um ihn mit dem JMX-Port Ihres Java-Prozesses zu verbinden .

Sie benötigen Zugriff auf Ihren Linux-Computer über SSH-Login. Die gesamte Kommunikation wird über die SSH-Verbindung getunnelt.

TIPP: Diese Lösung funktioniert unabhängig davon, ob eine Firewall vorhanden ist oder nicht.

Nachteil: Jedes Mal, wenn Sie Ihren Java-Prozess neu starten , müssen Sie alle Schritte von 4 bis 9 erneut ausführen.


1. Von hier aus benötigen Sie die Putty-Suite für Ihren Windows-Computer:

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

Zumindest die putty.exe


2. Definieren Sie einen freien Port auf Ihrem Linux-Computer:

<jmx-remote-port>

Beispiel:

jmx-remote-port = 15666      


3. Fügen Sie dem Java-Prozess auf dem Linux-Computer Argumente hinzu

Dies muss genau so erfolgen. Wenn es wie unten gemacht wird, funktioniert es für Linux-Maschinen hinter Firewalls (es funktioniert aufgrund des -Djava.rmi.server.hostname=localhostArguments).

-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

Beispiel:

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. Holen Sie sich die Prozess-ID Ihres Java-Prozesses

ps -ef | grep <java-processname>

result ---> <process-id>

Beispiel:

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

result ---> 24321


5. Suchen Sie einen beliebigen Port für den Download von RMIServer-Stubs

Der Java-Prozess öffnet einen neuen TCP-Port auf dem Linux-Computer, über den die RMI Server-Stubs zum Download zur Verfügung stehen. Dieser Port muss auch über den SSH-Tunnel verfügbar sein, um eine Verbindung zur Java Virtual Machine herzustellen.

Mit netstat -lpdiesem Port können Sie auch lsof -iHinweise geben, welcher Port aus dem Java-Prozess geöffnet wurde.

HINWEIS: Dieser Port ändert sich immer, wenn der Java-Prozess gestartet wird.

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>

Beispiel:

netstat -lp | grep 24321

tcp        0      0 *:15666     *:*     LISTEN      24321/java
tcp        0      0 *:37123     *:*     LISTEN      24321/java


result ---> 37123


6. Aktivieren Sie zwei SSH-Tunnel von Ihrem Windows-Computer mit 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

Beispiel:

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

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


Einstellungen zum Öffnen eines SSL-Tunnels über Putty


7. Melden Sie sich mit Putty mit aktiviertem SSH-Tunnel bei Ihrem Linux-Computer an.

Lassen Sie die Kitt-Sitzung offen.

Wenn Sie angemeldet sind, tunnelt Putty alle TCP-Verbindungen über den SSH-Port 22 zum Linux-Computer.

JMX-Port:

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

RMIServer-Stub-Port:

Windows Machine: localhost:37123   >>> SSH >>>   linux machine: localhost:37123


8. Starten Sie JConsole / Java VisualVM / Java Mission Control, um über die folgende URL eine Verbindung zu Ihrem Java-Prozess herzustellen

Dies funktioniert, da JConsole / Java VisualVM / Java Mission Control denkt, dass Sie eine Verbindung zu einem Port auf Ihrem lokalen Windows-Computer herstellen. Aber Putty sendet alle Nutzdaten an den Port 15666 an Ihren Linux-Computer.

Auf dem Linux-Computer gibt der Java-Prozess zuerst eine Antwort und sendet den RMIServer-Port zurück. In diesem Beispiel 37123.

Dann glaubt JConsole / Java VisualVM / Java Mission Control, dass es eine Verbindung zu localhost: 37123 herstellt, und putty sendet die gesamte Nutzlast an den Linux-Computer weiter

Der Java-Prozess antwortet und die Verbindung ist offen.

[x] Remote Process:
service:jmx:rmi:///jndi/rmi://localhost:<jndi-remote-port>/jmxrmi

Beispiel:

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


Stellen Sie eine Verbindung über die JMX-Service-URL her


9. GENIESSEN SIE # 8-]


1
Nur eine kleine Frage hier - eine JMX-Verbindung ohne rmi nicht möglich?
Kumar Vaibhav

5
Ich habe einen Hinweis erhalten, dass wir einen rmi.port auf eine feste Portnummer setzen können, damit wir den beliebigen Port für den Download von RMIServer-Stubs festlegen können. Dies sollte mit der Java-Eigenschaft "com.sun.management.jmxremote.rmi.port = <rmi-server-port>" funktionieren. Es sieht aus wie eine undokumentierte Funktion in der Oracle Java VM.
Sushicutta

1
Sicher schlägt es, Keystores und Trusted
Stores

Gleicher Vorgang, aber ich habe kein solches Objekt in der Tabelle
wener

2
@sushicutta Kannst du diesen Hinweis in deine Antwort einfügen, er funktioniert einwandfrei und kann die Schritte von 4 bis 6 entfernen. Der Haken ist, dass dein weitergeleiteter Port der gleiche sein muss wie der ursprüngliche Port und sowohl der jmx- als auch der rmi-Port müssen sei gleich
schäbig

80

Durch Hinzufügen wurde -Djava.rmi.server.hostname='<host ip>'dieses Problem für mich behoben.


2
In meinem Fall muss ich eine IP-Adresse hinzufügen (-Djava.rmi.server.hostname = <ip>). Hostname -i gab mir zwei IP-Adressen und die richtige war die zweite in der Liste.
Georgy Bolyuba

4
hat das Problem für mich nicht gelöst. Das Verbinden von Windows-2-Windows ist für mich kein Problem, ABER wenn ich versuche, eine Verbindung von einer JVM Jvisualvm.exe unter Windows herzustellen, um einen Java-Dienst zu überwachen, der unter SUSE mit Oracle JDK 1.6.024 ausgeführt wird, schlägt die Verbindung fehl. Aus diesem Grund denke ich, dass diese Personenfrage immer noch unbeantwortet bleibt.
Djangofan

Dies löste das Problem für mich. Dies plus die üblichen 3 (authentifizieren / port / ssl) gesetzt und ich kann jetzt remote verbinden. Die Box lauscht jedoch auf mehreren virtuellen Schnittstellen. Möglicherweise hat die Angabe des Hosts die JVM verwirrt.
Nicholi

Endlich meine Probleme beim Verbinden von jconsole auf meinem osx-Laptop gelöst. Vielen Dank.
Rado

Hat für mich gearbeitet. Danke dir!
Jeff

58

Versucht mit Java 8 und neueren Versionen

Diese Lösung funktioniert auch gut mit Firewalls

1. Fügen Sie dies Ihrem Java-Startskript auf dem Remote-Host hinzu:

-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. Führen Sie dies auf Ihrem Computer aus.

  • Windows-Benutzer :

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

  • Linux- und Mac-Benutzer :

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

3. Starten Sie jconsoleauf Ihrem Computer

jconsole localhost:1616

4. Viel Spaß!

PS: Verwenden Sie in Schritt 2 sshund geben -LSie an, dass der Port 1616 auf dem lokalen (Client-) Host an die Remote-Seite weitergeleitet werden muss. Dies ist ein SSH-Tunnel und hilft, Firewalls oder verschiedene Netzwerkprobleme zu vermeiden.


1
GENIAL!! Ich habe seit mehr als 6 Stunden versucht, jmx-remote auf eine ActiveMQ-Instanz unter java8 zu übertragen. ENDLICH ETWAS, DAS ARBEITET !! Vielen Dank! :)
Rop

Danke, wie du habe ich auch ungefähr einen Tag gekämpft und nach so viel Arbeit dachte ich nur: "Ich muss dieses Ding an SO schreiben !!"
Freedev

2
Saugt wirklich , dass Oracle nicht erwähnt „com.sun.management.jmxremote.rmi.port“, „java.rmi.server.hostname“ docs.oracle.com/javase/8/docs/technotes/guides/management/... I Ich denke, das war mein Problem.
Rop

Denn, AFAIK, bei diesem Problem geht es nicht um JMX, sondern darum, wie RMI funktioniert. Nach diesem Fall hatte ich beispielsweise das gleiche Problem mit jmeter, das rmi in seiner Client / Server-Implementierung verwendet.
Freedev

2
Es klappt. Nur meine Erfahrung mit den Tunneln hinzufügen: 1) kann "localhost" in "-L 1616: localhost: 1616" verwenden 2) kann den Quellport nicht ändern, dh dies wird nicht funktionieren: "-L 9999: localhost: 1616"
Gargii

19

Wahrscheinlich tritt ein Problem mit einer Firewall auf. Das "Problem" ist, dass der von Ihnen angegebene Port nicht der einzige verwendete Port ist, sondern 1 oder sogar 2 weitere Ports für RMI verwendet und diese wahrscheinlich von einer Firewall blockiert werden.

Einer der zusätzlichen Ports ist im Voraus nicht bekannt, wenn Sie die Standard-RMI-Konfiguration verwenden. Daher müssen Sie eine große Anzahl von Ports öffnen, was den Serveradministrator möglicherweise nicht amüsiert.

Es gibt eine Lösung, bei der nicht viele Ports geöffnet werden müssen. Ich habe sie jedoch mithilfe der kombinierten Quell-Snippets und Tipps von zum Laufen gebracht

http://forums.sun.com/thread.jspa?threadID=5267091 - Link funktioniert nicht mehr

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

http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html

Es ist sogar möglich, einen SSH-Tunnel einzurichten und trotzdem zum Laufen zu bringen :-)


2
Ich konnte die Firewall nur mit dem in simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html beschriebenen Alias umgehen und -Djava.rmi.server.hostname festlegen, wie in einer anderen Antwort hier erwähnt.
Damien

Hinweis für zukünftige Leser: Der Link zu forums.sun.comist unterbrochen
CDspace

1
Hinweis für zukünftige Leser: Der Link zu blogs.oracle.comist unterbrochen.
Grimlock

17

Nachdem ich mein Google-Fu in den letzten Tagen getestet hatte, konnte ich es endlich zum Laufen bringen, nachdem ich die Antworten von Stack Overflow und dieser Seite http://help.boomi.com/atomsphere/GUID-F787998C- zusammengestellt hatte. 53C8-4662-AA06-8B1D32F9D55B.html .

Reposting von der Dell Boomi-Seite:

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

Die eine Zeile, in der ich keine Stapelüberlauf-Antwortabdeckung gesehen habe, ist

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

In meinem Fall habe ich versucht, Kakfa-Metriken abzurufen, daher habe ich einfach die obige Option geändert, um sie an den -Dcom.sun.management.jmxremote.portWert anzupassen . Ohne jegliche Authentifizierung sollte die absolute Konfiguration folgendermaßen aussehen:

-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 eins für "Google-fu"
Kevinarpe

"com.sun.management.jmxremote.rmi.port" war auch für mich der Schlüssel. Siehe auch diese Antwort: stackoverflow.com/a/22306586/123205
David

Ich brauchte nicht "com.sun.management.jmxremote.local.only", also denke ich nicht, dass Ihre Konfiguration wirklich "absolutes Minimum" ist
David


7

Die Schritte 4 bis 7 von Sushicutta können übersprungen werden, indem Schritt 3 die folgende Zeile hinzugefügt wird:

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

zB Hinzufügen, um Parameter zu starten:

-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

Stellen Sie für die Portweiterleitung eine Verbindung her mit:

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

Wenn Ihr Gastgeber ein Sprungbrett ist, ketten Sie den Hafen einfach nach vorne, indem Sie auf dem Sprungbrett wie folgt Folgendes ausführen:

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

Beachten Sie, dass der Hostname = localhost benötigt wird, um sicherzustellen, dass die jmxremote der rmi-Verbindung anweist, den Tunnel zu verwenden. Andernfalls wird möglicherweise versucht, eine direkte Verbindung herzustellen und die Firewall zu erreichen.


Diese Methode hilft mir: (1) Ich füge fehlende JMX-Parameter hinzu und starte die App neu. (2) Dann ssh -L <JMX_port>:localhost:<JMX_port> <remote_user>@<remote_host> auf lokalem Computer ausführen. (3) Dann verbinde ich mich mit Remote-JMX mit: jconsole <remote_host>:<JMX_port>
Rib47

6

PROTIP:

Die RMI-Ports werden an beliebigen Portnr geöffnet. Wenn Sie eine Firewall haben und die Ports 1024-65535 nicht öffnen möchten (oder VPN verwenden möchten), müssen Sie die folgenden Schritte ausführen.

Sie müssen die RMI-Registrierungs- und JMX / RMI-Server-Ports (wie bei einer bekannten Nummer) reparieren. Sie tun dies, indem Sie eine JAR-Datei (Catalina-Jmx-Remote.JAR, die in den Extras enthalten ist) in das lib-Verzeichnis einfügen und einen speziellen Listener unter dem Server konfigurieren:

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

(Und natürlich die üblichen Flags zum Aktivieren von JMX

    -Dcom.sun.management.jmxremote  \
    -Dcom.sun.management.jmxremote.ssl=false \
    -Dcom.sun.management.jmxremote.authenticate=false \
    -Djava.rmi.server.hostname=<HOSTNAME> \

Siehe: JMX Remote Lifecycle Listener unter http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

Dann können Sie sich über diese schreckliche URL verbinden:

service:jmx:rmi://<hostname>:10002/jndi/rmi://<hostname>:10001/jmxrmi

Versuchte das oben genannte mit der Extras-JAR und kann sehen, dass die RMI-Ports wie angegeben abhören, aber zufällige Ports weiterhin von RMI verwendet werden, nachdem eine Verbindung zum JVM-Port mit VisualVM hergestellt wurde. Problemumgehung: Achten Sie auf Ports mit 'lsof -i' und öffnen Sie Ports mit blockierten Verbindungen.
Joseph Lust

5

Überprüfen Sie, ob sich Ihr Server hinter der Firewall befindet. JMX basiert auf RMI, das beim Start zwei Ports öffnet. Einer ist der Registerport, der Standardwert ist 1099 und kann durch die com.sun.management.jmxremote.portOption angegeben werden . Die andere dient der Datenkommunikation und ist zufällig, was zu Problemen führt. Eine gute Nachricht ist, dass ab JDK6 dieser zufällige Port durch die com.sun.management.jmxremote.rmi.portOption angegeben werden kann .

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

JMX durch die Firewall zu bekommen ist wirklich schwierig. Das Problem ist, dass Standard-RMI einen zweiten zufällig zugewiesenen Port verwendet (neben der RMI-Registrierung).

Wir haben drei Lösungen, die funktionieren, aber jeder Fall benötigt eine andere:

  1. JMX über SSH-Tunnel mit Socks-Proxy verwendet Standard-RMI mit SSH-Magie http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html

  2. JMX MP (Alternative zu Standard-RMI) verwendet nur einen festen Port, benötigt jedoch eine spezielle JAR auf Server und Client. Http://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/

  3. Starten Sie den JMX Server-Formularcode. Dort können Sie Standard-RMI verwenden und einen festen zweiten Port verwenden: https://issues.apache.org/bugzilla/show_bug.cgi?id=39055


Alle anderen Antworten sollten eine Ergänzung zu dieser sein
ruruskyi

2

Versuchen Sie beim Testen / Debuggen / Diagnostizieren von Remote- JMX-Problemen immer zuerst, eine Verbindung auf demselben Host herzustellen, auf dem sich der MBeanServer befindet (z. B. localhost), um Netzwerk- und andere nicht JMX-spezifische Probleme auszuschließen.


2

Hier gibt es bereits einige gute Antworten, aber es gibt einen etwas einfacheren Ansatz, den ich für sinnvoll halte.

Der Ansatz von sushicutta ist gut, aber sehr manuell, da Sie jedes Mal den RMI-Port erhalten müssen. Zum Glück können wir das umgehen, indem wir einen SOCKS-Proxy verwenden, anstatt die Port-Tunnel explizit zu öffnen. Der Nachteil dieses Ansatzes ist, dass die JMX-App, die Sie auf Ihrem Computer ausführen, für die Verwendung eines Proxys konfiguriert werden muss. Bei den meisten Prozessen können Sie dies durch Hinzufügen von Java-Eigenschaften tun. Einige Apps unterstützen dies jedoch nicht.

Schritte:

  1. Fügen Sie die JMX-Optionen zum Startskript für Ihren Remote-Java-Dienst hinzu:

    -Dcom.sun.management.jmxremote=true
    -Dcom.sun.management.jmxremote.port=8090
    -Dcom.sun.management.jmxremote.ssl=false
    -Dcom.sun.management.jmxremote.authenticate=false
    
  2. Richten Sie eine SOCKS-Proxy-Verbindung zu Ihrem Remote-Computer ein:

    ssh -D 9696 user@remotemachine.com
    
  3. Konfigurieren Sie Ihre lokale Java-Überwachungs-App für die Verwendung des SOCKS-Proxys (localhost: 9696). Hinweis: Sie können dies manchmal über die Befehlszeile tun, dh:

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

2

Folgendes hat für mich funktioniert (obwohl ich denke, dass Port 2101 nicht wirklich dazu beigetragen hat):

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

Ich verbinde mich von einem Remotecomputer mit einem Server, auf dem Docker ausgeführt wird und der Prozess sich im Container befindet. Außerdem habe ich firewallD gestoppt, aber ich glaube nicht, dass dies das Problem war, da ich auch bei geöffneter Firewall auf 2100 telneten konnte. Ich hoffe es hilft.


1

Ich verwende JConsole / JVisualVm unter Windows, das mit Tomcat verbunden ist und Linux Redhat ES3 ausführt.

Das Deaktivieren der Paketfilterung mit dem folgenden Befehl hat den Trick für mich getan:

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

Dabei ist jconsole-host entweder der Hostname oder die Hostadresse, auf der JConsole ausgeführt wird, und jmxremote-port ist die für com.sun.management.jmxremote.port für die Remoteverwaltung festgelegte Portnummer.


2
hat bei einer SUSE Amazon EC2-Instanz nicht funktioniert. Ich denke, das Problem liegt anderswo.
Djangofan

1

Ich verwende boot2docker, um Docker-Container mit Tomcat auszuführen, und ich habe das gleiche Problem. Die Lösung war:

  • Hinzufügen -Djava.rmi.server.hostname=192.168.59.103
  • Verwenden Sie denselben JMX-Port im Host- und Docker-Container, zum Beispiel : docker run ... -p 9999:9999 .... Die Verwendung verschiedener Ports funktioniert nicht.

0

Sie müssen auch sicherstellen, dass Ihr Computername in die IP aufgelöst wird, an die JMX gebunden ist. Weder localhost noch 127.0.0.1. Für mich hat es geholfen, einen Eintrag in Hosts einzufügen, der dies explizit definiert.


0

JMX durch die Firewall zu bringen ist gar nicht so schwer. Es gibt einen kleinen Haken. Sie müssen beide von JMX konfigurierten Ports weiterleiten, d. H. 9010 und einer der dynamischen Ports, die er auf meinem Computer abhört, war> 30000


0

Dies sind die Schritte, die für mich funktioniert haben (Debian hinter der Firewall auf der Serverseite, über VPN von meinem lokalen Mac aus erreichbar):

Überprüfen Sie die Server-IP

hostname -i

Verwenden Sie JVM-Parameter:

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

Anwendung ausführen

Finden Sie die PID des laufenden Java-Prozesses

Überprüfen Sie alle von JMX / RMI verwendeten Ports

netstat -lp | grep [pid from step 4]

Öffnen Sie alle Ports ab Schritt 5 der Firewall

Voila.


0

Um einen Beitrag zu leisten, habe ich dies unter CentOS 6.4 für Tomcat 6 getan.

  1. Iptables-Dienst herunterfahren

    service iptables stop
    
  2. Fügen Sie die folgende Zeile zur tomcat6.conf hinzu

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

Auf diese Weise konnte ich mit JConsole eine Verbindung von einem anderen PC herstellen.


0

Ich versuche JMC, den Flight Recorder (JFR) auszuführen, um NiFi auf einem Remote-Server zu profilieren, der keine grafische Umgebung zum Ausführen von JMC bietet.

Basierend auf den anderen hier gegebenen Antworten und nach vielen Versuchen und Irrtümern liefere ich der JVM ( conf / bootstrap.conf ) Folgendes, wenn ich NiFi starte:

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)

Ich habe dies in / etc / hosts eingefügt , obwohl ich bezweifle, dass es benötigt wird:

10.10.10.92   localhost

Beim Starten von JMC erstelle ich dann eine Remoteverbindung mit den folgenden Eigenschaften:

Host: 10.10.10.92
Port: 9098
User: (nothing)
Password: (ibid)

Wenn ich übrigens auf die URL des benutzerdefinierten JMX-Dienstes klicke, wird Folgendes angezeigt:

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

Das hat es endlich für mich getan.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.