Кто-нибудь когда-либо получал удаленный JMX JConsole для работы?

Кажется, что у меня никогда не было этого, чтобы работать в прошлом. В настоящее время я ЗНАЮ, что он не работает.

Но мы запускаем наш Java-процесс:

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

Я могу использовать telnet для порта, и "что-то есть" (то есть, если я не запускаю процесс, ничего не отвечает, но если да, то это так), но я не могу заставить JConsole работать в IP и порту.

Похоже, это должно быть так просто, но никаких ошибок, шума, ничего. Просто не работает.

Кто-нибудь знает горячий отзыв для этого?

ОТВЕТЫ

Ответ 1

У меня есть решение для этого:

Если ваш процесс 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-машин за брандмауэрами (оно вызывает причину аргумента -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. Получить идентификатор процесса вашего 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 Tunnel для подключения к виртуальной машине 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


Settings to open an SSL tunnel via Putty


7. Войдите в свою Linux-машину с помощью Putty с включенным SSH-туннелем.

Оставьте сеанс шпаклевки открытым.

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

JMX-Port:

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

RMIServer-Сто-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. В этом примере 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


Connect via jmx service url


9. ENJOY # 8 -]

Ответ 2

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

Ответ 3

Пробовал с Java 8

Это решение хорошо работает и с брандмауэрами

1. Добавьте это в свой java-запуск script на удаленном хосте:

-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 [email protected] -L 1616:remote-host:1616

  • Пользователи Linux и Mac:

    ssh [email protected] -L 1616:remote-host:1616

3. Запустите jconsole на вашем компьютере

jconsole localhost:1616

4. Получайте удовольствие!

P.S.: во время шага 2, используя ssh и -L, вы указываете, что порт 1616 на локальном (клиентском) хосте должен быть перенаправлен на удаленную сторону. Это туннель ssh и помогает избежать брандмауэров или проблем с сетями.

Ответ 4

Вероятно, у вас возникла проблема с брандмауэром. "Проблема" в том, что указанный вами порт не является единственным используемым портом, он использует 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 и заставить его работать: -)

Ответ 5

После сдачи моего теста Google-фу в течение последних нескольких дней я наконец смог заставить это работать после компиляции ответов из Qaru и этой страницы 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)

Ответ 7

ПРОТИВ:

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

Вам необходимо исправить (как при наличии известного номера) порты RMI и порты JMX/RMI. Вы делаете это, помещая 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 Remote Lifecycle Listener в http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

Затем вы можете подключиться с помощью этого ужасающего URL-адреса:

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

Ответ 8

Проверьте, находится ли ваш сервер за брандмауэром. 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"

Ответ 9

Шаги Sushicutta 4-7 можно пропустить, добавив следующую строку к шагу 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-подключению использовать туннель. В противном случае он может попытаться подключить directy и нажать брандмауэр.

Ответ 10

Получение JMX через брандмауэр действительно сложно. Проблема в том, что стандартный RMI использует второй случайный назначенный порт (помимо реестра RMI).

У нас есть три решения, которые работают, но каждый случай нуждается в другом:

Ответ 11

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

Ответ 12

Здесь уже есть отличные ответы, но есть несколько более простой подход, который, я думаю, стоит поделиться.

sushicutta подход хорош, но очень ручной, так как вам нужно каждый раз получать порт RMI. К счастью, мы можем обойти это, используя прокси-сервер SOCKS, а не явно открывая портовые туннели. Недостатком такого подхода является приложение JMX, которое вы запускаете на вашем компьютере, чтобы иметь возможность настроить прокси-сервер. Большинство процессов вы можете сделать это, добавив свойства java, но некоторые приложения не поддерживают это.

Шаги:

  • Добавьте параметры JMX к запуску script для вашей удаленной службы Java:

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

  • Настройте подключение прокси-сервера SOCKS к удаленному компьютеру:

    ssh -D 9696 [email protected]

  • Настройте локальное приложение мониторинга Java для использования прокси-сервера SOCKS (localhost: 9696). Примечание. Иногда вы можете сделать это из командной строки, то есть:

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

Ответ 13

Я запускаю 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 для удаленного управления.

Ответ 14

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

  • Добавить -Djava.rmi.server.hostname=192.168.59.103
  • Используйте один и тот же порт JMX в контейнере хоста и докера, например: docker run ... -p 9999:9999 .... Использование разных портов не работает.

Ответ 15

Вам также необходимо убедиться, что имя вашего компьютера разрешено для IP-адреса, к которому привязан JMX; НЕ localhost или 127.0.0.1. Для меня это помогло помещать запись в хосты, которая явно определяет это.

Ответ 16

Получение JMX через брандмауэр не так уж и тяжело. Есть один небольшой улов. Вы должны перенаправить оба настроенных порта JMX, т.е. 9010 и один из динамических портов, который он прослушивает на моей машине, это было > 30000

Ответ 17

Это шаги, которые сработали для меня (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 на брандмауэре

Voila.

Ответ 18

Чтобы внести свой вклад, это то, что я сделал для CentOS 6.4 для Tomcat 6.

  • Завершение работы iptables

    service iptables stop

  • Добавьте следующую строку в 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.

Ответ 19

Я пытаюсь 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

Это, наконец, сделало это для меня.