Новые возможности мониторинга Java приложений в Zabbix 3.4

Что случилось?


Вышел долгожданный релиз Zabbix 3.4, который принёс много полезных улучшений, среди которых оказались настраиваемые JMX endpoints и гибкое обнаружение MBean«ов.


Это так круто, да?


Если вы используете Zabbix и вам требуется мониторить Java приложения, то да — это может сильно облегчить вам жизнь, потому что раньше приходилось прибегать к различным ухищрениям, а теперь всё работает, как говорится, «из коробки».


qvw2wa0xxdhcuikbzaz5paw2ef0.png


А что не так с этими JMX endpoints?


Нативный мониторинг Java приложений через JMX появился в Zabbix давно — начиная с версии 2.0 — и с тех пор этот функционал улучшается от версии к версии. Но так вышло, что в предыдущих релизах JMX endpoint был жёстко зашит в код Zabbix Java Gateway совершенно наивным образом.
zgnmtzme7oeam_rcyg1-cx3c_a8.png
Как выяснилось, в мире Java существует масса софта, который использует иные endpoints, а старые версии Zabbix не позволяли менять этот параметр. Для многих пользователей это стало реальной проблемой. Например, популярный сервер приложений JBoss EAP 6 использует для удалённого доступа к JMX свой протокол JBoss Remoting вместо RMI и JMXServiceURL для него должен выглядеть так:


service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}


А, например, WebSphere 8.5 использует RMI поверх IIOP (а не JRMP) и для него JMXServiceURL должен быть таким:


service:jmx:iiop://{HOST.CONN}:{HOST.PORT}/jndi/JMXConnector


Zabbix 3.4 как раз решает эту проблему.


Я ничего не понял. JMX, RMI, JNDI? WTF?


Хорошо-хорошо, давайте немного разберёмся, как всё это работает.
JMX (Java Management Extensions) — технология Java, предназначенная для мониторинга и управления (в т.ч. удалённо) различными объектами (ресурсами): приложениями, устройствами, сетями — лишь бы этот объект был написан на Java.


Эти ресурсы называются MBeans (ManagedBeans). Каждый такой объект реализует определённый интерфейс, через который можно получить доступ к значениям атрибутов этого объекта, а также вызвать его методы и получать уведомления (если приложение зарегистрирует соответствующие «слушающие» MBean«ы).


MBeans регистрируются на MBean Server — реестре объектов. Любой зарегистрированный объект становится доступным для приложений (точнее, становится доступным его интерфейс).
Доступ к ресурсам осуществляется при помощи JMX-коннекторов, которые делают MBean Server доступным для JMX-клиентов. JMX-коннектор состоит из клиента и сервера. Коннектор-сервер соединяется с MBean-сервером и слушает запросы соединений от клиентов. Коннектор-клиент обычно находится на другой JVM, а чаще всего вообще на другой машине по отношению к коннектор-серверу.


JMX API имеет стандартный протокол подключения, основанный на Remote Method Invocation (RMI). Этот протокол позволяет JMX-клиенту удалённо получить доступ к MBean«ам на MBean-сервере. Кроме штатного RMI существуют и другие протоколы: JMXMP, JBoss Remoting, Hessian, Burlap, и даже HTTP и SNMP.


Используя интерфейс MBean«а клиент может получать различные метрики этого объекта, а также вызывать публичные методы.


Схематично взаимодействие компонентов можно изобразить так:


aduixuz2y4abwb_n9ad9p3vjym8.png


Любое приложение на платформе Java SE «из коробки» имеет возможности для его мониторинга: RMI коннектор автоматически делает доступным ваше Java приложение для удалённого управления и мониторинга. Достаточно лишь запустить приложение с нужными параметрами, и JMX-клиенты (а Zabbix Java Gateway — это JMX-клиент) уже смогут подключаться к нему удалённо и получать нужные метрики.


Чтобы указать JMX-клиенту конкретное приложение, к которому вы хотите подключиться, используется специальный адрес, который называется JMX endpoint (он же JMXServiceURL). Если говорить строже, то это адрес коннектор-сервера JMX API. Формат этого адреса определяется RFC 2609 и RFC 3111. В общем случае он выглядит так:


service:jmx:protocol:sap


Где «service: jmx:» — константа.
protocol — это транспортный протокол (один из многих: RMI, JMXMP, etc), используемый для подключения к коннектор-серверу.
sap — адрес, по которому коннектор-сервер может быть найден. Задаётся в таком формате (это подмножество синтаксиса, определённого в RFC 2609):


//[host[:port]][url-path]


host[: port] — ipv4 адрес хоста (или ipv6, заключённый в квадратные скобки) и необязательный (в зависимости от протокола) номер порта.
url-path — необязательный URL (обязательность зависит от протокола).


Лучше всего разобраться с этим на примере. Часто можно встретить такой JMX endpoint, вид которого некоторых может ввести в ступор:


service:jmx:rmi://host:port1/jndi/rmi://host:port2/jmxrmi


Но на самом деле не всё так страшно.
rk5hsyhv6ofb_lbwh9i981whp6e.png
host — это целевой хост, где запущено наше приложение.
port1 — это порт RMI-сервера, к которому мы хотим подключиться.
, а port2 — это порт RMI registry (каталог, где регистрируются RMI-серверы). По умолчанию: 1099.


Если знать о том, что RMI-реестр выдаёт адрес и порт RMI-сервера по запросу клиента, то становится понятно, что первая часть здесь лишняя. Таким образом адрес можно сократить до такого вида:
hyqwdwphckkvuckh_stjj6phqtq.png
url-path часть означает буквально следующее: возьми ту часть URL, которая следует сразу за /jndi/ и выполни по этому адресу JNDI-запрос в RMI registry, чтобы получить информацию об RMI-сервере. Реестр вернёт в ответ его хост и порт.
Следует отметить, что порт в таком случае генерируется случайным образом и могут возникнуть проблемы с настройкой файрвола. В таких случаях и используют предыдущий вариант записи JMX endpoint«а, потому что он позволяет явно указать порт.


Если вам хотелось бы глубже разобраться в JMX, то рекомендуем обратиться к официальной документации Oracle.


Может лучше на практике?


Нет ничего проще:) Давайте для примера попробуем настроить мониторинг JBoss EAP 6.4.


Для начала сделаем несколько предположений:


  1. Вы уже установили Zabbix 3.4 и Zabbix Java Gateway. Если еще нет, то вы можете сделать это в соответствии с документацией Zabbix.
  2. Zabbix Server и Java Gateway с префиксом /usr/local/.
  3. JBoss уже установлен в /opt/jboss-eap-6.4/ и запускается в standalone режиме.
  4. Для простоты эксперимента будем считать, что все эти компоненты работают на одной и той же машине.
  5. Firewall и SELinux отключены (или настроены соответствующим образом, но это выходит за рамки статьи).


Сделаем несколько простых настроек в zabbix_server.conf:


JavaGateway=127.0.0.1
StartJavaPollers=5


И в конфиге zabbix_java/settings.sh (или zabbix_java_gateway.conf):


START_POLLERS=5


Проверьте, что JBoss слушает свой стандартный management port:


$ netstat -natp | grep 9999
tcp        0      0 127.0.0.1:9999          0.0.0.0:*               LISTEN      10148/java


Теперь давайте создадим в Zabbix хост с JMX интерфейсом 127.0.0.1:9999.
txn_th3uz9jw20b1xb9dlgpwbey.png
Если мы сейчас просто возьмём стандартный шаблон «Template App Generic Java JMX» и прилинкуем его к хосту, то наверняка получим ошибку:


$ tail -f /tmp/zabbix_java.log


qmuns2mty_9l6_jsg9_rgzmpjki.png
Java Gateway сообщает нам, что по указанному endpoint отвечает совсем не RMI. Хорошо, мы уже знаем, что эта версия JBoss использует протокол JBoss Remoting вместо RMI, и нам нужно лишь начать стучаться в правильный endpoint.


Давайте сделаем Full Clone шаблона «Template App Generic Java JMX» и назовём его «Template App Generic Java JMX-remoting». Выделим все элементы данных внутри этого шаблона и выполним операцию Mass update для параметра JMX endpoint. Пропишем такой URL:


service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}


ssrskvtsgs8o_6abdgxj-ppj_yu.png


Обновим конфигурационный кэш:


$ /usr/local/sbin/zabbix_server -R config_cache_reload


И снова ошибка.
rlp5rjqpor9xysqpkxokuy8qfju.png
Что на этот раз?
«Unsupported protocol: remoting-jmx» означает, что Java Gateway не умеет работать с указанным протоколом. Что ж, давайте его научим. В этом нам поможет совет из статьи «JBoss EAP 6 monitoring using remoting-jmx and Zabbix».


Создадим файл ~/needed_modules.txt со следующим содержимым:


jboss-as-remoting
jboss-logging
jboss-logmanager
jboss-marshalling
jboss-remoting
jboss-sasl
jcl-over-slf4j
jul-to-slf4j-stub
log4j-jboss-logmanager
remoting-jmx
slf4j-api
xnio-api
xnio-nio


Выполним команду:


$ for i in $(cat ~/needed_modules.txt); do find /opt/jboss-eap-6.4 -iname ${i}*.jar -exec cp {} /usr/local/sbin/zabbix_java/lib/ \; ; done


Таким образом, Java Gateway будет иметь все необходимые модули для работы с jmx-remoting. Остаётся лишь перезапустить Java Gateway, немного подождать и, если вы всё сделали правильно, увидеть, что заветные данные начали поступать в Zabbix:
26zhp0gmei42jjhnod-zhpu0ba8.png
mh9jqlja6anypwy3xvcxwlzynu4.png


А что там с JMX обнаружением?


JMX обнаружение появилось в Zabbix одновременно с появлением нативной поддержки мониторинга Java приложений через JMX. За эту функцию отвечает недокументированный (на тот момент) ключ jmx.discovery. В документации о нём не было ни слова, потому что это была ещё очень сырая функция:
-fd_cemtvwonct4lndfw6qonmqm.png


  1. В таком обнаружении нет особого смысла, потому что нет никаких возможностей для фильтрации. А вряд ли кому-то требуется обнаруживать все существующие JMX-объекты.
  2. Это очень медленное решение, т.к. здесь выполняется по одному запросу на каждый MBean, а их может быть довольно много. Очень вероятно, что такая проверка просто отвалится по таймауту.
  3. В таком виде можно создать лишь одно правило обнаружения в рамках хоста, что весьма печально, потому что на практике хотелось бы создавать множество правил (банально могут отличаться типы данных для разных атрибутов).


В Zabbix 3.4 появилась возможность фильтрации, что сразу решает многие проблемы.
Новая проверка выглядит так: jmx.discovery[<режим обнаружения>,<имя объекта>]
И позволяет указать, требуется ли обнаружение MBean’ов или их атрибутов, а также по какому шаблону их искать.
Давайте попробуем её в деле! Замониторим, к примеру, сборщики мусора. Известно, что их имена могут различаться в зависимости от того, с какими параметрами запущена JVM. А значит мы не можем задать статичные имена и ключи для элементов данных — это работёнка как раз для jmx.discovery.
Документация описывает нам четыре примера использования:


Ключ Описание
jmx.discovery Получение всех JMX MBean атрибутов
jmx.discovery[beans] Получение всех JMX MBeans
jmx.discovery[attributes,"*:type=GarbageCollector,name=*"] Получение всех атрибутов сборщика мусора
jmx.discovery[beans,"*:type=GarbageCollector,name=*"] Получение всех сборщиков мусора


Первые два варианта мы использовать не будем, т.к. это не очень хорошо с точки зрения производительности. Посмотрим, что возвращают нам два последних.
Для этой цели мы можем просто создать item с нужным нам ключом и текстовым типом данных. Но это не очень удобно. Во-первых, вывод будет неформатированным и ненаглядным. Во-вторых, чтобы изменить запрос, нам всякий раз придётся изменять ключ item’а и какое-то время ждать обновления данных.


Это не наш путь. Давайте лучше сделаем что-то вроде zabbix_get, только вместо агента будем обращаться к Java Gateway. Для этого немного доработаем предложенный в этой заметке скрипт под новый API: добавим jmx_endpoint в запрос и поправим удаление заголовка из ответа:


#!/usr/bin/env bash

if [ $# != 6 ]
then
    echo "Usage: $0      "
    exit;
fi

# create connection
exec 3<>/dev/tcp/$1/$2

# compose message
MSG="{\"request\": \"java gateway jmx\", \"conn\": \"$3\", \"port\": $4, \"jmx_endpoint\": \"$5\", \"keys\": [\"$6\"]}"

# write message length as zero-padded 16-digit hexadecimal number
printf -v LEN '%016x' "${#MSG}"

# prepare message length in little endian representation
BYTES=""
for i in {0..14..2}
do
    BYTES="\\x${LEN:$i:2}$BYTES"
done

# prepend protocol header and message length
printf "ZBXD\\1$BYTES%s" "$MSG" >&3

# output the result skipping 6 bytes of "ZBXD\\1" header and 8 bytes of message length
tail -c+14 <&3


Теперь мы с лёгкостью можем посмотреть, что возвращает нам шлюз в ответ на наши запросы:


$ ./zabbix_get_java.sh 127.0.0.1 10052 127.0.0.1 9999 'service:jmx:remoting-jmx://127.0.0.1:9999' 'jmx.discovery[beans,\"*:type=GarbageCollector,name=*\"]' | jq '.data[0].value | fromjson | .data'


xp30zjczkrtghxyivpxo0oyqsqa.png
zd3n95pwrkej8kyn4v10gnhy7ba.png
То что нужно!
Если бы нам требовалась, допустим, всего пара метрик, то мы могли бы обнаружить все gc и создать на каждую метрику по прототипу.


  1. Создаём правило обнаружения. Ищем MBean’ы (кстати, обратите внимание, что везде используется кастомный JMX endpoint).
    1c-q8exio3s6-vpbtvksarf1kfs.png
  2. Создаём прототипы на каждую интересующую нас метрику. В имени элемента данных и его ключе мы можем использовать любые макросы, которые видели в JSON’е.
    uxhvjml5h7tqxb8qp0cysufkyic.png


1xcjbmborn3jojwcw4ibehv2f9e.png


Кстати, о макросах. При обнаружении MBean’ов макросы генерируются динамически на основе свойств MBean’ов (таких как type и name).


Обратите внимание на эту проблему при использовании динамических макросов: https://support.zabbix.com/browse/ZBX-12705

Но, допустим, мы хотим создать все доступные числовые метрики по сборщикам мусора.


  1. Тогда мы создадим правило обнаружения атрибутов с фильтром по типу данных.
    3daic1kgeh7nipje_rz7z_wgkiu.png


4hr6vr0-oc7xtqjdk3ulluk7a-c.png


  1. И всего лишь один прототип:
    hzico0fn-5opke9c_mrfxky9fbg.png


zqigiquopipuabiitm8p7jj4tuw.png


Вот таким нехитрым образом можно замониторить любое Java приложение. Дерзайте! :)


У меня сейчас нет возможности обновиться на Zabbix 3.4, как мне быть?


Сообщество придумало множество способов как обойти эту проблему. Если у вас пока нет возможности обновиться на эту версию, то вот вам ссылки: раз и два.


Итог


Благодаря новым реализованным возможностям мониторинг Java приложений в Zabbix перестал быть болью. Напротив, с каждой новой версией это становится всё более простым и приятным занятием :) Будем стараться радовать вас и дальше!


Stay tuned!


P.S. Статья также доступна на английском языке в нашем блоге.
P.S. S. Статьи о других нововведениях Zabbix 3.4:


  • Обзор Zabbix 3.4
  • О массовом сборе данных и препроцессинге


Список использованной литературы


  • http://java-course.ru/articles/jmx/
  • http://www.javaspecialist.ru/2011/04/jmx-firewall.html
  • https://docs.oracle.com/javase/tutorial/jmx/remote/index.html
  • https://dzone.com/articles/remote-jmx-access-wildfly-or
  • https://habrahabr.ru/post/225527/
  • https://jcp.org/en/jsr/detail? id=160
  • https://www.denniskanbier.nl/blog/monitoring/jboss-eap-6-monitoring-using-remoting-jmx-and-zabbix/
  • https://www.ibm.com/developerworks/ru/library/j-jtp09196/index.html
  • https://www.ixxus.com/blog/blog201102monitor-and-manage-alfresco-jmx/

© Habrahabr.ru