Wygląda na to, że w przeszłości nigdy to nie działało. Obecnie WIEM, że to nie działa.

Ale zaczynamy nasz proces Java:

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

Mogę telnetować się do portu i "coś tam jest" (to znaczy, jeśli nie rozpocznę procesu, nic nie odpowiada, ale jeśli to zrobię, to robi), ale nie mogę zmusić JConsole do pracy wypełniania adresu IP i port.

Wydaje się, że to powinno być takie proste, ale bez błędów, bez hałasu, bez niczego. Po prostu nie działa.

Czy ktoś zna gorącą wskazówkę?

Mam na to rozwiązanie:

Jeśli Twój proces Java działa w systemie Linux za zaporą ogniową i chcesz uruchomić JConsole / Java VisualVM / Java Mission Control w systemie Windows na komputerze lokalnym, aby podłączyć go do portu JMX procesu Java .

Potrzebujesz dostępu do swojego komputera z systemem Linux poprzez logowanie SSH. Cała komunikacja będzie tunelowana przez połączenie SSH.

WSKAZÓWKA: To rozwiązanie działa bez względu na to, czy jest zapora, czy nie.

Wada: za każdym razem, gdy restartujesz proces Java, będziesz musiał ponownie wykonać wszystkie kroki od 4 do 9.

1. Potrzebujesz zestawu szpachli do swojego komputera z systemem Windows stąd:

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

Przynajmniej putty.exe

2. Zdefiniuj jeden wolny port na swoim komputerze z systemem Linux:

<jmx-remote-port>

Przykład:

jmx-remote-port = 15666      

3. Dodaj argumenty do procesu java na komputerze z systemem Linux

Należy to zrobić dokładnie w ten sposób. Jeśli zostanie to zrobione jak poniżej, działa na maszynach linuxowych za zaporami ogniowymi (działa jako przyczyna -Djava.rmi.server.hostname=localhostargumentu).

-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

Przykład:

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. Uzyskaj identyfikator procesu swojego procesu Java

ps -ef | grep <java-processname>

result ---> <process-id>

Przykład:

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

result ---> 24321

5. Znajdź dowolny port dla pobierania kodów pośredniczących RMIServer

Proces java otwiera nowy port TCP na komputerze z systemem Linux, skąd będzie można pobrać pliki RMI Server-Stubs. Ten port musi być również dostępny za pośrednictwem tunelu SSH, aby uzyskać połączenie z wirtualną maszyną Java.

Dzięki netstat -lptemu portowi można również znaleźć lsof -ipodpowiedź, który port został otwarty z procesu Java.

UWAGA: Ten port zawsze się zmienia po uruchomieniu procesu Java.

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>

Przykład:

netstat -lp | grep 24321

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


result ---> 37123

6. Włącz dwa tunele SSH na komputerze z systemem Windows za pomocą szpachli

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

Przykład:

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

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

7. Zaloguj się do swojej maszyny Linux z Putty z włączonym tunelem SSH.

Pozostaw sesję szpachlową otwartą.

Kiedy jesteś zalogowany, Putty tuneluje wszystkie połączenia TCP do komputera z systemem Linux przez port 22 SSH.

Port JMX:

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

RMIServer-Stub-Port:

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

8. Uruchom JConsole / Java VisualVM / Java Mission Control, aby połączyć się z procesem Java przy użyciu następującego adresu URL

To działa, ponieważ JConsole / Java VisualVM / Java Mission Control myśli, że łączysz się z portem na lokalnym komputerze z systemem Windows. ale Putty wysyła cały ładunek do portu 15666 na twój komputer z systemem Linux.

Na komputerze z systemem Linux najpierw proces java daje odpowiedź i odsyła port RMIServer. W tym przykładzie 37123.

Następnie JConsole / Java VisualVM / Java Mission Control uważa, że ​​łączy się z localhost: 37123 i putty wyśle ​​cały ładunek do komputera z systemem Linux

Proces java odpowiada i połączenie jest otwarte.

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

Przykład:

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

9. ENJOY # 8-]

Dodanie -Djava.rmi.server.hostname='<host ip>'rozwiązało ten problem za mnie.

Próbowałem z Javą 8 i nowszymi wersjami

To rozwiązanie działa również dobrze z zaporami ogniowymi

1. Dodaj to do skryptu startowego java na zdalnym hoście:

-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. Wykonaj to na swoim komputerze.

• Użytkownicy systemu Windows :

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

• Użytkownicy systemów Linux i Mac :

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

3. Uruchom jconsolekomputer

jconsole localhost:1616

4. Baw się dobrze!

PS: w kroku 2, używając sshi -Lokreślasz, że port 1616 na hoście lokalnym (klienta) musi być przekierowany na stronę zdalną. To jest tunel ssh i pomaga uniknąć zapór ogniowych lub różnych problemów z siecią.

Prawdopodobnie masz problem z zaporą. `` Problem '' polega na tym, że określony port nie jest jedynym używanym portem, używa 1 lub nawet 2 dodatkowych portów dla RMI, a te są prawdopodobnie blokowane przez zaporę ogniową.

Jeden z dodatkowych portów nie będzie znany z góry, jeśli użyjesz domyślnej konfiguracji RMI, więc musisz otworzyć duży zakres portów - co może nie rozbawić administratora serwera.

Istnieje rozwiązanie, które nie wymaga otwierania wielu portów, jednak uruchomiłem je przy użyciu połączonych fragmentów kodu źródłowego i wskazówek z

http://forums.sun.com/thread.jspa?threadID=5267091 - link już nie działa

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

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

Można nawet skonfigurować tunel ssh i nadal go uruchamiać :-)

Po przetestowaniu mojego Google-fu przez ostatnie kilka dni, w końcu udało mi się to uruchomić po skompilowaniu odpowiedzi ze Stack Overflow i tej strony http://help.boomi.com/atomsphere/GUID-F787998C- 53C8-4662-AA06-8B1D32F9D55B.html .

Ponowne publikowanie ze strony 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

Jedyna linia, w której nie widziałem żadnej odpowiedzi na temat przepełnienia stosu, to

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

W moim przypadku próbowałem pobrać metryki Kakfa, więc po prostu zmieniłem powyższą opcję, aby pasowała do -Dcom.sun.management.jmxremote.portwartości. Tak więc, bez jakiegokolwiek uwierzytelniania, podstawowa minimalna konfiguracja powinna wyglądać następująco:

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

Czy pracujesz w systemie Linux? Być może agent zarządzania jest powiązany z hostem lokalnym:

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

Kroki 4-7 Sushicutty można pominąć, dodając następujący wiersz do kroku 3:

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

np. Dodaj do parametrów uruchamiania:

-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

W przypadku przekierowania portów połącz się za pomocą:

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

jeśli twój host jest odskocznią, po prostu połącz port naprzód, wykonując następujące czynności na schodku po powyższym:

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

Pamiętaj, że hostname = localhost jest potrzebny, aby upewnić się, że jmxremote mówi połączeniu rmi, aby używał tunelu. W przeciwnym razie może spróbować połączyć się bezpośrednio i uderzyć w zaporę.

OCHRONA:

Port RMI jest otwierany w dowolnym porcie. Jeśli masz zaporę ogniową i nie chcesz otwierać portów 1024-65535 (ani używać sieci VPN), musisz wykonać następujące czynności.

Musisz naprawić (tak jak w przypadku znanego numeru) rejestr RMI i porty serwera JMX / RMI. Robisz to, umieszczając plik jar (catalina-jmx-remote.jar jest w dodatkach) w katalogu lib-dir i konfigurując specjalny odbiornik na serwerze:

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

(I oczywiście zwykłe flagi do aktywacji JMX

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

Zobacz: JMX Remote Lifecycle Listener pod adresem http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

Następnie możesz połączyć się za pomocą tego przerażającego adresu URL:

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

Sprawdź, czy serwer znajduje się za zaporą. JMX jest oparty na RMI, które otwierają dwa porty po uruchomieniu. Jeden to port rejestru, domyślny to 1099 i można go określić za pomocą com.sun.management.jmxremote.portopcji. Drugi służy do przesyłania danych i jest losowy, co jest przyczyną problemu. Dobra wiadomość jest taka, że ​​z JDK6 ten losowy port można określić com.sun.management.jmxremote.rmi.portopcją.

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"

Przejście JMX przez Firewall jest naprawdę trudne. Problem polega na tym, że standardowy RMI używa drugiego losowo przydzielonego portu (poza rejestrem RMI).

Mamy trzy rozwiązania, które działają, ale każdy przypadek wymaga innego:

1. JMX over SSH Tunnel z proxy Socks, używa standardowego RMI z magią SSH http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html

2. JMX MP (alternatywa dla standardowego RMI), używa tylko jednego stałego portu, ale potrzebuje specjalnego jar na serwerze i kliencie http://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/

3. Uruchom kod formularza JMX Server, tam można użyć standardowego RMI i użyć stałego drugiego portu: https://issues.apache.org/bugzilla/show_bug.cgi?id=39055

Podczas testowania / debugowania / diagnozowania zdalnych problemów JMX, najpierw zawsze próbuj połączyć się na tym samym hoście, który zawiera MBeanServer (tj. Localhost), aby wykluczyć problemy z siecią i inne problemy nie specyficzne dla JMX.

Jest tu już kilka świetnych odpowiedzi, ale istnieje nieco prostsze podejście, którym warto się podzielić.

Podejście sushicutta jest dobre, ale jest bardzo ręczne, ponieważ za każdym razem musisz uzyskać port RMI. Na szczęście możemy to obejść, używając proxy SOCKS zamiast jawnie otwierać tunele portów. Wadą tego podejścia jest to, że aplikacja JMX uruchamiana na komputerze musi być skonfigurowana do korzystania z serwera proxy. Większość procesów można to zrobić, dodając właściwości Java, ale niektóre aplikacje tego nie obsługują.

Kroki:

1. Dodaj opcje JMX do skryptu startowego dla zdalnej usługi Java:

   -Dcom.sun.management.jmxremote=true
   -Dcom.sun.management.jmxremote.port=8090
   -Dcom.sun.management.jmxremote.ssl=false
   -Dcom.sun.management.jmxremote.authenticate=false
   

2. Skonfiguruj połączenie proxy SOCKS ze zdalnym komputerem:

   ssh -D 9696 [email protected]
   

3. Skonfiguruj lokalną aplikację monitorującą Java do korzystania z serwera proxy SOCKS (localhost: 9696). Uwaga: czasami można to zrobić z wiersza poleceń, np .:

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

Poniższe działały dla mnie (chociaż myślę, że port 2101 tak naprawdę nie przyczynił się do tego):

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

Łączę się ze zdalnej maszyny na serwer, na którym działa Docker, a proces znajduje się wewnątrz kontenera. Ponadto zatrzymałem firewallD, ale nie sądzę, żeby to był problem, ponieważ mogłem telnetować się do 2100 nawet przy otwartej zaporze. Mam nadzieję, że to pomoże.

Używam JConsole / JVisualVm na Windowsie podłączając się do tomcat z Linux Redhat ES3.

Wyłączenie filtrowania pakietów za pomocą następującego polecenia załatwiło sprawę:

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

gdzie jconsole-host to nazwa hosta lub adres hosta, na którym działa JConsole, a jmxremote-port to numer portu ustawiony dla com.sun.management.jmxremote.port do zdalnego zarządzania.

Używam boot2dockera do uruchamiania kontenerów docker z Tomcat w środku i mam ten sam problem, rozwiązaniem było:

• Dodaj -Djava.rmi.server.hostname=192.168.59.103
• Używać tego samego portu JMX w gospodarza i Döcker pojemnika, na przykład: docker run ... -p 9999:9999 .... Używanie różnych portów nie działa.

Musisz również upewnić się, że nazwa twojego komputera jest tłumaczona na adres IP, z którym łączy się JMX; NIE localhost ani 127.0.0.1. Dla mnie pomogło umieszczenie wpisu do hostów, który wyraźnie to definiuje.

Przejście JMX przez zaporę nie jest wcale takie trudne. Jest jeden mały haczyk. Musisz przekazać oba porty skonfigurowane przez JMX, tj. 9010, a jeden z portów dynamicznych, którego nasłuchuje na moim komputerze to> 30000

Oto kroki, które zadziałały dla mnie (debian za firewallem po stronie serwera, osiągnięty przez VPN z mojego lokalnego Maca):

sprawdź adres IP serwera

hostname -i

użyj parametrów 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]

uruchom aplikację

znajdź pid uruchomionego procesu Java

sprawdź wszystkie porty używane przez JMX / RMI

netstat -lp | grep [pid from step 4]

otwórz wszystkie porty od kroku 5 na zaporze

Voila.

Aby wnieść swój wkład, tak właśnie zrobiłem na CentOS 6.4 dla Tomcat 6.

1. Wyłącz usługę iptables

   service iptables stop
   

2. Dodaj następujący wiersz do 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]"
   

W ten sposób mogłem połączyć się z innego komputera za pomocą JConsole.

Próbuję JMC uruchomić Rejestrator lotu (JFR), aby profilować NiFi na zdalnym serwerze, który nie oferuje środowiska graficznego, na którym można uruchomić JMC.

W oparciu o inne odpowiedzi podane tutaj i na podstawie wielu prób i błędów, oto co dostarczam do JVM ( conf / bootstrap.conf ), kiedy uruchamiam 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)

Umieściłem to w / etc / hosts , chociaż wątpię, czy jest to potrzebne:

10.10.10.92   localhost

Następnie po uruchomieniu JMC tworzę zdalne połączenie o tych właściwościach:

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

Nawiasem mówiąc, jeśli kliknę adres URL niestandardowej usługi JMX, widzę:

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

To w końcu zrobiło to dla mnie.