Подтвердить что ты не робот

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

Я пытаюсь открыть соединение JMX с java-приложением, запущенным на удаленной машине.

Приложение JVM настроено со следующими параметрами:

  • com.sun.management.jmxremote
  • com.sun.management.jmxremote.port = 1088
  • com.sun.management.jmxremote.authenticate = ложь
  • com.sun.management.jmxremote.ssl = ложь

Я могу подключиться с помощью localhost:1088 с помощью jconsole или jvisualvm. Но я не могу подключиться с помощью xxx.xxx.xxx.xxx:1088 с удаленной машины.

Между серверами или ОС нет брандмауэра. Но для устранения этой возможности я telnet xxx.xxx.xxx.xxx 1088 и я думаю, что она подключается, так как экран консоли становится пустым.

Оба сервера - это Windows Server 2008 x64. Пробовал с 64-битным JVM и 32-битным, не работает.

4b9b3361

Ответ 1

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

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

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

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

Ответ 2

Я потратил больше одного дня, пытаясь заставить 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.

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Этот трюк работал у меня.

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

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, только от реальных физических удаленных хостов. Итак, я полагаю, что эта проверка выполняется только тогда, когда соединение происходит от "снаружи".

Ответ 6

Большое спасибо, он работает следующим образом:

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

Чтобы включить удаленный JMX, пройдите ниже параметров VM вместе с командой 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

Ответ 10

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