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?

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

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

9. GENIESSEN SIE # 8-]

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

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.

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

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)

Laufen Sie unter Linux? Möglicherweise ist der Verwaltungsagent an localhost gebunden:

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

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.

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

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

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

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.

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 [email protected]
   

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
   

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.

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.

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.

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.

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

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.

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.

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.