Czy ktoś kiedykolwiek miał zdalną konsolę JMX JConsole do pracy?


120

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


3
Jeśli używasz tomcata, może to być rozwiązanie: stackoverflow.com/questions/1263991/ ...
Hajo Thelen

5
Czy zapomniałeś zaakceptować coś tutaj @Will?
Gray

Odpowiedzi:


126

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


Ustawienia otwierania tunelu SSL przez Putty


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


Połącz przez adres URL usługi jmx


9. ENJOY # 8-]


1
Tylko małe pytanie - nie można zrobić połączenia JMX bez rmi?
Kumar Vaibhav

5
Otrzymałem wskazówkę, że możemy ustawić rmi.port na stały numer portu, więc możemy ustawić dowolny port do pobierania stubów RMIServer. powinno to działać z właściwością Java „com.sun.management.jmxremote.rmi.port = <rmi-server-port>”. Wygląda na nieudokumentowaną funkcję w Oracle Java VM.
sushicutta

1
Z pewnością pokonuje konieczność konfigurowania
magazynów

Ten sam proces, ale nie mam takiego obiektu w tabeli
wener

2
@sushicutta, czy możesz dodać tę wskazówkę w swojej odpowiedzi, działa doskonale i może usunąć kroki od 4 do 6, haczyk polega na tym, że Twój przekierowany port musi być taki sam jak oryginalny port, a zarówno port jmx, jak i rmi również muszą bądź taki sam
odrapany

80

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


2
W moim przypadku muszę dodać adres IP (-Djava.rmi.server.hostname = <ip>). nazwa_hosta -i dała mi dwa adresy IP, a poprawny był drugi na liście.
Georgy Bolyuba

4
nie rozwiązało problemu za mnie. podłączenie windows-2-windows nie jest dla mnie problemem, ALE kiedy próbuję połączyć się z JVM Jvisualvm.exe w systemie Windows, aby monitorować usługę java działającą w SUSE z Oracle JDK 1.6.024, połączenie kończy się niepowodzeniem. Z tego powodu myślę, że to pytanie nadal pozostaje bez odpowiedzi.
djangofan

To rozwiązało problem. To plus zwykły zestaw 3 (uwierzytelnianie / port / ssl) i mogę teraz połączyć się zdalnie. Pudełko nasłuchuje na wielu wirtualnych interfejsach, być może dlatego nie określono hosta, który zmylił jvm.
Nicholi

W końcu rozwiązałem moje problemy z połączeniem jconsole na moim laptopie z systemem OSX. Dzięki.
rado

Pracował dla mnie. Dziękuję Ci!
Jeff

58

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


1
NIESAMOWITE!! Od ponad 6 godzin próbuję połączyć się z jmx-remote do instancji ActiveMQ w java8. WRESZCIE COŚ, CO DZIAŁAŁO !! Dzięki! :)
Rop

Dzięki, tak jak Ty też walczyłem przez około jeden dzień i po tak ciężkiej pracy pomyślałem: „Muszę to napisać do SO !!”
freedev

2
Naprawdę jest do bani, że Oracle nie wspomina o „com.sun.management.jmxremote.rmi.port”, „java.rmi.server.hostname” docs.oracle.com/javase/8/docs/technotes/guides/management/… I chyba to był mój problem.
Rop

Ponieważ, AFAIK, ten problem nie dotyczy JMX, ale tego, jak działa RMI. Na przykład po tym przypadku miałem ten sam problem z jmeterem, który używa rmi w swojej implementacji klient / serwer.
freedev

2
To działa. Dodając tylko moje doświadczenie z tunelami: 1) mogę użyć "localhost" w "-L 1616: localhost: 1616" 2) nie mogę zmienić portu źródłowego, tzn. To nie zadziała: "-L 9999: localhost: 1616"
gargii

19

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


2
Udało mi się obejść zaporę ogniową, używając tylko aliasu opisanego w simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html wraz z ustawieniem -Djava.rmi.server.hostname, jak wspomniano w innej odpowiedzi tutaj.
Damien

Uwaga dla przyszłych czytelników: link do forums.sun.comjest uszkodzony
CDspace

1
Uwaga dla przyszłych czytelników: link do blogs.oracle.comjest uszkodzony.
Grimlock,

17

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)

1
Plus jeden za „Google-fu”
kevinarpe

„com.sun.management.jmxremote.rmi.port” też był dla mnie kluczem. Zobacz także tę odpowiedź: stackoverflow.com/a/22306586/123205
David

Nie potrzebowałem „com.sun.management.jmxremote.local.only”, więc nie sądzę, że twoja konfiguracja jest naprawdę „absolutnym minimum”
David


7

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


Ta metoda pomaga mi: (1) dodaję pominięte parametry JMX i restartuję aplikację (2) Następnie uruchamiam ssh -L <JMX_port>:localhost:<JMX_port> <remote_user>@<remote_host> na komputerze lokalnym (3) Następnie łączę się ze zdalnym JMX za pomocą: jconsole <remote_host>:<JMX_port>
Rib47

6

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

Wypróbowałem powyższe w / the extras jar i widzę, że porty RMI nasłuchują zgodnie ze specyfikacją, ale losowe porty nadal są używane przez RMI po połączeniu z portem JVM za pomocą VisualVM. Obejście: wypatruj portów z „lsof -i” i otwórz te z zablokowanymi połączeniami.
Joseph Lust

5

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"

4

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


Wszystkie inne odpowiedzi powinny być dodatkiem do tej
ruruskyi

2

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.


2

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

2

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.


1

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.


2
nie działa dla mnie na instancji SUSE Amazon EC2. Myślę, że problem leży gdzie indziej.
djangofan

1

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.

0

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.


0

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


0

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.


0

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.


0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.