2011-02-18 12 views
6

Przepraszamy za to pytanie, które musiało zostać zadane wiele razy, ale nie mogę rozwiązać problemu. Czytałem wiele blogów, stron, forów, ... i nie znalazłem żadnego rozwiązania w moim przypadku.VisualVM przez zapory sieciowe - rozwiązywanie problemów z RMI

koperty: muszę połączyć VisualVM na mojej skrzynce na odległych serwerach (Kocurek, weblogics) do monitorowania wydajności/wątków/pamięci. Te serwery są zainstalowane na (fizycznych lub wirtualnych) maszynach, które są chronione zaporą ogniową. Duże przedziały portów są otwarte w zaporze i mogą być używane, ale nie wszystkie porty.

Testy

  • Próbowałem bezpośrednie połączenia poprzez JMX w VisualVM, wykorzystując następujące opcje JVM po stronie serwera przy starcie serwera:
     
    -Djava.rmi.server.hostname=[hostname] 
    -Dcom.sun.management.jmxremote 
    -Dcom.sun.management.jmxremote.port=[port] 
    -Dcom.sun.management.jmxremote.ssl=false 
    -Dcom.sun.management.jmxremote.authenticate=false 
    

Mam sprecyzował nazwa hosta, ponieważ z mojej sieci nazwa hosta i adres IP serwera nie są takie same jak te z sieci zdalnego serwera.

Bez powodzenia, VisualVM zawsze wydaje się szukać nieznanego serwera.

  • próbował począwszy jstatd na stronie serwera na porcie dostępny (opcja -p) z mojej skrzynki (telnet na port) to działa, ale przy uruchamianiu VisualVM na tym hoście z jstatd portu, to nadal wydaje oczekiwanie na coś nieosiągalnego ... To samo zachowanie z połączeniem jps z tym zdalnym hostem.

  • próbował użyć tych samych narzędzi na serwerze z mniejszą ochroną sieci i działa. Tak więc widziałem połączenia między moim polem a serwerem i są one wykonywane na portach innych niż określone dla jstatd. Rozumiem, że ten port jest potrzebny do pierwszej komunikacji (rodzaj uzgadniania), a prawdziwa komunikacja odbywa się na innych portach, ale nie jest możliwa do przewidzenia (np. 60305, 55197, ...). Nie jestem pewien, czy dobrze rozumiem działanie RMI.

Proszę, pomóż mi, ja wariuję!

+0

Jeśli korzystasz z aktualizacji Java 7 4, istnieje nadzieja z flagą '' -Dcom.sun.management.jmxremote.rmi.port = 7091'' Zobacz ten wpis na blogu: http://hirt.se/ blog /? p = 289 – davey

Odpowiedz

7

Niestety, JMX próbuje otworzyć porty inne niż skonfigurowane. Zaledwie wczoraj udało mi się podłączyć do kocurka za firewallem przez JMX. Obie części skomplikowane są:

  • umieścić plik o nazwie jmxremote.access w CATALINA_HOME/conf, który zawiera następujące wiersze:

    monitorRole readonly 
    controlRole readwrite 
    
  • w server.xml określone porty, które będą używane przez JMX, poprzez specjalny detektor Tomcat (catalina-jmx-remote.jar wymagane/lib)

    <Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" 
        rmiRegistryPortPlatform="9009" rmiServerPortPlatform="9010" /> 
    

Następnie otwórz te dwa porty na zaporze. To działa. Ale to tylko dla kocurka.

Inną opcją jest użycie ssh tunnelling. W skrócie - łączysz się przez SSH i konfigurujesz go, aby przekazywał jakiś lokalny port (gdzie działa klient jmx) do niektórych portów po drugiej stronie tunelu.

Referencje:

+2

Powinieneś dodać, że trzeba również skopiować 'catalina-jmx-remote.jar' do' CATALINA_HOME/libs' w przeciwnym wypadku zostanie zgłoszony 'ClassNotFoundException'. Więcej informacji na ten temat można znaleźć na stronie http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html#JMX_Remote_Lifecycle_Listener_-_org.apache.catalina.mbeans.JmxRemoteLifecycleListener – ubuntudroid

0

Na [nazwa hosta], otwiera szereg [port] oraz port TCP 40000-60000 tylko dla Twojego IP. Zrobiło to dla mnie dość dobrze.

+0

. Dlaczego ta odpowiedź została tak mocno odrzucona? To jedyny, który mi pomógł. –

+2

Ponieważ otwarcie prawie wszystkich portów twojego komputera na resztę świata może działać na maszynie programistycznej, ale na pewno nie jest to możliwe w środowisku produkcyjnym/korporacyjnym. –

1

Oto kroki, aby to zrobić:

  1. uruchomić ejstatd w zdalnym hostem w ten sposób (w folderze ejstatd): mvn exec:java -Djava.rmi.server.hostname=[remote_host_name] -Dexec.args="-pr 1099 -ph 1100 -pv 1101" (stosowany dla "jstatd" połączenie typu)
  2. uruchomić aplikację Java z tymi dodatkowymi parametrami Java: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1102 -Dcom.sun.management.jmxremote.rmi.port=1102 -Djava.rmi.server.hostname=[remote_host_name] (używane dla połączenia typu "JMX") (java.rmi.server.hostname jest wymagany tylko dlatego, że adres IP i nazwa hosta z twojej sieci nie są takie same jak z punktu widzenia serwera)
  3. Otwórz te 4 porty na swoim zdalny host i udostępnić go swoim local machine: 1099, 1100, 1101 i 1102
  4. Wprowadzenie JVisualVM
    1. prawym przyciskiem myszy na "Remote"> "Dodaj hosta zdalnego ..." i wpisz nazwę zdalnego hosta w "Nazwa hosta" (Jeśli nie używaj portu 1099, możesz to zmienić w "Ustawieniach zaawansowanych")
    2. Kliknij prawym przyciskiem myszy host zdalny, który właśnie utworzyłeś> "Dodaj połączenie JMX ..." i wpisz "" w " Połączenie "wprowadź i sprawdź" Nie wymaga połączenia SSL "
    3. Twój proces Java pojawi się dwa razy: jeden z" jstatd " "typ połączenia i jeden z typu połączenia" JMX ".

Disclaimer: Jestem autor open source ejstatd narzędzia.