Удаленное соединение JMX

Если бы это было в Linux, проблема была бы в том, что localhost является интерфейсом обратной связи, вам нужно, чтобы приложение было привязано к вашему сетевому интерфейсу.

Вы можете использовать netstat, чтобы подтвердить, что он не привязан к ожидаемому сетевому интерфейсу.

Вы можете выполнить эту работу, вызвав программу с системным параметром java.rmi.server.hostname="YOUR_IP", либо как переменную среды, либо используя

java -Djava.rmi.server.hostname=YOUR_IP YOUR_APP

Я потратил больше дня, пытаясь заставить JMX работать вне localhost. Похоже, что SUN / Oracle не смогли предоставить хорошую документацию по этому поводу.

Убедитесь, что следующая команда вернет вам реальный IP-адрес или HOSTNAME. Если он вернет что-то вроде 127.0.0.1, 127.0.1.1 или localhost, он не будет работать, и вам придется обновить /etc/hosts файл.

hostname -i

Вот команда, необходимая для включения JMX даже извне

-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.port=1100
-Djava.rmi.server.hostname=myserver.example.com

Где, как вы предполагали, myserver.example.com должен соответствовать тому, что возвращает hostname -i.

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

В моем тестировании с Tomcat и Java 8 JVM открывала эфемерный порт в дополнение к порту, указанному для JMX. Следующий код исправил меня; попробуйте, если у вас возникли проблемы, когда ваш JMX-клиент (например, VisualVM не подключается.

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

Также см. Почему Java открывает 3 порта, когда JMX настроен?

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

Если вы пытаетесь получить доступ к серверу, который находится за NAT, вам, скорее всего, придется запустить свой сервер с опцией

-Djava.rmi.server.hostname=<public/NAT address>

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

похоже, что ваша финальная цитата идет слишком рано. Он должен быть после последнего параметра.

У меня этот трюк сработал.

Я заметил кое-что интересное: когда я запускаю свое приложение, используя следующую командную строку:

java -Dcom.sun.management.jmxremote.port=9999
     -Dcom.sun.management.jmxremote.authenticate=false
     -Dcom.sun.management.jmxremote.ssl=false

Если я попытаюсь подключиться к этому порту с удаленного компьютера с помощью jconsole, TCP-соединение будет успешным, некоторые данные будут обмениваться между удаленной jconsole и локальным jmx-агентом, где развернут мой MBean, а затем jconsole отобразит сообщение об ошибке подключения. Я выполнил захват Wirehark, и он показывает, что обмен данными происходит как от агента, так и от jconsole.

Таким образом, это не проблема сети, если я выполняю netstat -an с системным свойством java.rmi.server.hostname или без него, у меня будут следующие привязки:

 TCP    0.0.0.0:9999           0.0.0.0:0              LISTENING
 TCP    [::]:9999              [::]:0                 LISTENING

Это означает, что в обоих случаях сокет, созданный на порту 9999, принимает соединения с любого хоста по любому адресу.

Я думаю, что содержимое этого системного свойства используется где-то при подключении и сравнивается с фактическим IP-адресом, используемым агентом для связи с jconsole. И если эти адреса не совпадают, соединение не устанавливается.

У меня не было этой проблемы при подключении с одного и того же хоста с помощью jconsole, только с реальных физических удаленных хостов. Итак, я предполагаю, что эта проверка выполняется только тогда, когда соединение идет "извне".

у меня сработало то, что я установил / etc / hosts, чтобы указать имя хоста на ip, а не на интерфейс обратной связи, а затем перезапустить мое приложение.

кошка / etc / hosts

127.0.0.1      localhost.localdomain localhost
192.168.0.1    myservername

Это моя конфигурация:

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

Большое спасибо, это работает так:

java -Djava.rmi.server.hostname = xxx.xxx.xxx.xxx -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl = false -Dcom.sun.management.jmxremote.authenticate = false -Dcom.sun.management.jmxremote.port = 25000 -jar myjar .jar

Я знаю, что эта ветка довольно старая, но есть дополнительная опция, которая очень поможет. См. Здесь: https://realjenius.com/2012/11/21/java7-jmx-tunneling-freedom/

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

У меня такая же проблема, и я меняю любое имя хоста, которое соответствует имени локального хоста, на 0.0.0.0, похоже, после этого оно работает.

Чтобы включить удаленный JMX, передайте параметры виртуальной машины вместе с командой JAVA.

    -Dcom.sun.management.jmxremote 
    -Dcom.sun.management.jmxremote.port=453
    -Dcom.sun.management.jmxremote.authenticate=false                               
    -Dcom.sun.management.jmxremote.ssl=false 
    -Djava.rmi.server.hostname=myDomain.in

Попробуйте это, я тестировал доступ к JMX внутри контейнера докеров

-Dcom.sun.management.jmxremote = true -Djava.rmi.server.hostname = localhost -Dcom.sun.management.jmxremote.port = 16000 -Dcom.sun.management.jmxremote.rmi.port = 16000 -Dcom.sun .management.jmxremote.authenticate = false -Dcom.sun.management.jmxremote.ssl = false

потом

Локальный хост $ jconsole: 16000

Попробуйте использовать порты выше 3000.