Здається, я ніколи цього не працював. В даний час я знаю, що це не працює.

Але ми запускаємо наш процес Java:

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

Я можу зателефонувати до порту, і "щось там є" (тобто, якщо я не запускаю процес, нічого не відповідає, але якщо я це зробив), але я не можу змусити JConsole працювати над заповненням IP і порт.

Здається, це повинно бути таким простим, але без помилок, без шуму, без нічого. Просто не працює.

Хтось знає гарячу пораду для цього?

У мене є рішення для цього:

Якщо ваш Java-процес працює на Linux за брандмауером, і ви хочете запустити JConsole / Java VisualVM / Java Mission Control в Windows на локальній машині, щоб підключити його до порту JMX вашого процесу Java .

Вам потрібен доступ до вашої машини Linux через SSH логін. Вся комунікація буде налаштована через з'єднання SSH.

Порада. Це рішення працює незалежно від того, є брандмауер чи ні.

Недолік: Щоразу, коли ви перезапускаєте процес Java, вам потрібно буде робити всі кроки від 4 до 9 знову.

1. Вам потрібен комплект шпаклівки для вашої машини Windows звідси:

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

Принаймні putty.exe

2. Визначте один вільний порт на вашій машині Linux:

<jmx-remote-port>

Приклад:

jmx-remote-port = 15666      

3. Додайте аргументи до процесу java на машині Linux

Це потрібно зробити саме так. Якщо це зроблено, як показано нижче, він працює для linux Machines за брандмауерами (Це працює причиною -Djava.rmi.server.hostname=localhostаргументу).

-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

Приклад:

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. Отримайте Process-Id вашого Java-процесу

ps -ef | grep <java-processname>

result ---> <process-id>

Приклад:

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

result ---> 24321

5. Знайдіть довільний порт для завантаження заглушок RMIServer

Процес java відкриває новий порт TCP на машині linux, де для завантаження будуть доступні RMI Server-Stubs. Цей порт також повинен бути доступний через тунель SSH для підключення до віртуальної машини Java.

З netstat -lpцим портом можна знайти також lsof -iпідказки, який порт був відкритий у процесі Java.

ПРИМІТКА. Цей порт завжди змінюється при запуску 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>

Приклад:

netstat -lp | grep 24321

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


result ---> 37123

6. Увімкніть два тунелі SSH зі своєї машини Windows за допомогою шпаклівки

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

Приклад:

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

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

7. Увійдіть на свою машину Linux за допомогою програми Putty з цим SSH-тунелем.

Залиште сеанс шпаклівки відкритим.

Коли ви ввійдете в систему, Putty буде тунелювати всі TCP-підключення до машини Linux через порт SSH 22.

Порт JMX:

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

RMIServer-Stub-Port:

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

8. Запустіть JConsole / Java VisualVM / Java Mission Control, щоб підключитися до вашої програми Java за допомогою наступної URL-адреси

Це працює, тому що JConsole / Java VisualVM / Java Mission Control думає, що ви підключитесь до порту на локальній машині Windows. але Putty відправляє все корисне навантаження на порт 15666 на вашу машину Linux.

На машині Linux спочатку процес Java дає відповідь і повертає назад RMIServer Port. У цьому прикладі 37123.

Тоді JConsole / Java VisualVM / Java Mission Control вважає, що він підключається до localhost: 37123 і putty відправить весь корисний вантаж вперед на машину Linux

Java Process відповідає, і з'єднання відкрите.

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

Приклад:

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

9. ПРАВИЛО # 8]

Додавання -Djava.rmi.server.hostname='<host ip>'вирішило цю проблему для мене.

Пробував з Java 8 та новішими версіями

Це рішення добре працює і з брандмауерами

1. Додайте це до сценарію запуску Java на віддаленому хості:

-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. Виконайте це на своєму комп’ютері.

• Користувачі Windows :

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

• Користувачі Linux та Mac :

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

3. Почніть jconsoleна комп’ютері

jconsole localhost:1616

4. Веселіться!

PS: під час кроку 2, використовуючи sshта -Lвказуючи, що порт 1616 на локальному (клієнтському) хості повинен бути пересланий на віддалену сторону. Це ssh-тунель і допомагає уникнути брандмауерів або різних проблем з мережею.

Напевно, виникла проблема із брандмауером. «Проблема» полягає в тому, що вказаний вами порт не є єдиним використовуваним портом, він використовує 1 або, можливо, навіть ще 2 порти для RMI, і вони, ймовірно, блокуються брандмауером.

Якщо ви використовуєте конфігурацію RMI за замовчуванням, один із додаткових портів не буде відомий наперед, тому вам доведеться відкрити великий діапазон портів, що може не потішити адміністратора сервера.

Є рішення, яке не потребує відкриття багато портів, однак я змусив його працювати за допомогою комбінованих фрагментів джерела та порад від

http://forums.sun.com/thread.jspa?threadID=5267091 - посилання більше не працює

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

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

Можна навіть налаштувати ssh-тунель і все-таки змусити його працювати :-)

Після того, як я поставив тест Google протягом останніх кількох днів, я, нарешті, зміг змусити це працювати після складання відповідей із переповнення стека та цієї сторінки http://help.boomi.com/atomsphere/GUID-F787998C- 53C8-4662-AA06-8B1D32F9D55B.html .

Повторне повідомлення зі сторінки 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

Єдиний рядок, в якому я не бачив жодної обкладинки відповідей на переповнення стека

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

У моєму випадку я намагався отримати показники Kakfa, тому я просто змінив вищевказаний варіант, щоб відповідати -Dcom.sun.management.jmxremote.portзначенню. Отже, без автентифікації будь-якого типу, мінімальний конфігурація повинна виглядати так:

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

Ви працюєте в Linux? Можливо, агент управління прив'язує до localhost:

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

Кроки 4-7 Sushicutta можна пропустити, додавши наступний рядок до кроку 3:

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

наприклад Додати для запуску параметрів:

-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

Для переадресації порту підключіться за допомогою:

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

якщо ваш хост - це сходовий камінь, просто ланцюг порту вперед, виконавши наступне на кроці після вищезазначеного:

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

Зверніть увагу, що ім'я хоста = localhost потрібно, щоб переконатися, що jmxremote повідомляє про з'єднання rmi, щоб використовувати тунель. В іншому випадку він може спробувати підключити прямо і потрапити в брандмауер.

ПОРАДА:

Порт RMI відкривається на довільному portnr. Якщо у вас є брандмауер і ви не хочете відкривати порти 1024-65535 (або використовувати vpn), вам потрібно зробити наступне.

Вам потрібно виправити (як у відомого номера) порти реєстру RMI та сервера JMX / RMI Server. Ви робите це, додаючи jar-файл (catalina-jmx-remote.jar - це в додаткові) у lib-dir та налаштовуючи спеціального слухача під сервер:

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

(І звичайно звичайні прапори для активації JMX

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

Див. Слухач віддаленого життєвого циклу JMX на веб-сайті http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

Потім ви можете підключитися за допомогою цієї жахливої ​​URL-адреси:

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

Перевірте, чи ваш сервер знаходиться за брандмауером. JMX - це база на RMI, яка відкриває два порти під час її запуску. Один - порт регістра, за замовчуванням - 1099, і його можна вказати com.sun.management.jmxremote.portопцією. Інший - для передачі даних, і є випадковим, що є причиною проблеми. Хороша новина полягає в тому, що з JDK6 цей випадковий порт можна вказати com.sun.management.jmxremote.rmi.portопцією.

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 через брандмауер справді важко. Проблема полягає в тому, що стандартний RMI використовує другий випадковий призначений порт (поруч із реєстром RMI).

У нас є три рішення, які працюють, але кожен випадок потребує іншого:

1. JMX через тунель SSH з проксі-носками Socks, використовує стандартний RMI з SSH магією http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html

2. JMX MP (альтернатива стандартній RMI), використовує лише один фіксований порт, але йому потрібна спеціальна банка на сервері та клієнті http://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/

3. Запустіть код форми сервера JMX, там можна використовувати стандартний RMI та використовувати фіксований другий порт: https://isissue.apache.org/bugzilla/show_bug.cgi?id=39055

Під час тестування / налагодження / діагностики віддалених проблем JMX, спершу завжди намагайтеся підключитися до того самого хоста, який містить MBeanServer (тобто localhost), щоб виключити мережеві та інші проблеми, що не стосуються JMX.

Тут вже є кілька чудових відповідей, але є дещо простіший підхід, який, на мою думку, варто поділитися.

Підхід sushicutta хороший, але дуже ручний, тому що ви повинні отримувати порт RMI кожен раз. На щастя, ми можемо обійти це, використовуючи проксі-сервер SOCKS, а не відкриваючи тунелі портів. Недоліком цього підходу є додаток JMX, яке запускається на вашому комп'ютері, щоб мати можливість налаштувати проксі-сервер. У більшості процесів ви можете це зробити, додаючи властивості Java, але деякі програми не підтримують це.

Кроки:

1. Додайте параметри JMX до сценарію запуску для віддаленої служби 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. Налаштуйте проксі-з'єднання SOCKS до віддаленої машини:

   ssh -D 9696 user@remotemachine.com
   

3. Налаштуйте локальну програму моніторингу Java для використання проксі-сервера SOCKS (localhost: 9696). Примітка. Іноді це можна зробити з командного рядка, тобто:

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

Наступне працювало для мене (хоча я думаю, що порт 2101 насправді не сприяв цьому):

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

Я підключаюсь від віддаленої машини до сервера, на якому працює Докер, і процес знаходиться всередині контейнера. Крім того, я зупинив firewallD, але я не думаю, що це було проблемою, оскільки я міг звертатися до 2100 навіть при відкритому брандмауері. Сподіваюся, це допомагає.

Я запускаю JConsole / JVisualVm на Windows, підключившись до tomcat під управлінням Linux Redhat ES3.

Відключення фільтрації пакетів за допомогою наступної команди зробило для мене фокус:

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

де jconsole-host - це або ім'я хоста, або адреса хоста, на якій працює JConsole, а jmxremote-port - номер порту, встановлений для com.sun.management.jmxremote.port для віддаленого управління.

Я використовую boot2docker для запуску контейнерів докера з Tomcat всередині, і у мене є та сама проблема, рішенням було:

• Додайте -Djava.rmi.server.hostname=192.168.59.103
• Використовуйте один і той же порт JMX в хост і Докер контейнері, наприклад: docker run ... -p 9999:9999 .... Використання різних портів не працює.

Вам також потрібно переконатися, що ім'я машини відповідає IP, до якого JMX зобов'язує; НЕ localhost ні 127.0.0.1. Для мене це допомогло поставити запис у хости, що це чітко визначає.

Пройти JMX через брандмауер зовсім не так складно. Є один невеликий улов. Ви повинні переслати обидва порту, налаштованого JMX, тобто. 9010, і один з динамічних портів його слухав на моїй машині, це було> 30000

Це кроки, які працювали для мене (debian за брандмауером на стороні сервера, досягнутий через VPN від мого локального Mac):

перевірити ip сервера

hostname -i

використовувати параметри 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]

запустити додаток

знайти pid запущеного процесу Java

перевірити всі порти, що використовуються JMX / RMI

netstat -lp | grep [pid from step 4]

відкрити всі порти з кроку 5 на брандмауері

Вуаля.

Для того, щоб зробити внесок, це я зробив у CentOS 6.4 для Tomcat 6.

1. Служба iptables відключення

   service iptables stop
   

2. Додайте наступний рядок до 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]"
   

Таким чином я зміг підключитися з іншого ПК за допомогою JConsole.

Я намагаюся JMC запустити Flight Recorder (JFR) для профілю NiFi на віддаленому сервері, який не пропонує графічного середовища, на якому запускати JMC.

Виходячи з інших наведених тут відповідей, і після багатьох спроб та помилок, ось що я постачаю до JVM ( conf / bootstrap.conf ), коли запускаю 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)

Я поставив це в / etc / hosts , хоча я сумніваюся, що це потрібно:

10.10.10.92   localhost

Потім, запустивши JMC, я створюю віддалене з'єднання з цими властивостями:

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

До речі, якщо натиснути користувальницьку URL-адресу служби JMX, я побачу:

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

Це нарешті зробило це для мене.