Zabbix + JMX ( Мониторинг состояния Java-приложений по протоколу JMX. )

OS: "Linux Debian 8/9 (Jessie/Stretch)", "Linux Ubuntu 16/18 (Xenial/Bionic) LTS".
Application: "Zabbix v3.4", "Zabbix Java Gateway v3.4".

Задача: обеспечить техническую возможность посредством системы мониторинга "Zabbix" отслеживать текущее состояния Java приложений, запущенных к контейнеризаторах "Tomcat" и "WildFly", путём обращений к JMX (Java Management eXtensions).

Специально для мониторинга Java-приложений разработчиками "Zabbix" был создан инструмент "Zabbix Java Gateway", запускаемый в виде отдельного сервиса - с точки зрения пользователя системы мониторинга представляющий собой один из компонентов сервера мониторинга, вроде тех, что отрабатывают обращения к "Zabbix Agent"-ам, SNMP и IPMI - точно также все JMX-запросы будут отправлены сервису "Zabbix Java Gateway", который по специализированному протоколу свяжется с "Tomcat" или "WildFly", запросит и получит требуемое значение , после чего перенаправит его серверу мониторинга.


Предварительная подготовка.

Сервис "Zabbix Java Gateway" написан на "Java" и требует для работы наличия соответствующего интерпретатора - достаточно "OpenJDK v9 Headless":


Проверяем, та ли версия Java используется для запуска приложений "по умолчанию":




Установка "Zabbix Java Gateway".

По состоянию на 2018-й год инструментарий мониторинга Java-приложений в "Zabbix" явно не выведен на уровень полной готовности, так что в публичных репозиториях Linux-ов его пока нет. Достаточно просто подключить репозиторий разработчиков и загрузить необходимый пакет ПО оттуда:




Ради одного пакета можно не подключаться к репозиторию, а скачать его напрямую (ссылка на ПО для "Linux Ubuntu"), но тогда потеряется возможность его простого обновления.

Настройка спарки "Zabbix Server" и "Zabbix Java Gateway".

Настроек режима запуска "шлюза" немного, и параметры по умолчанию меня полностью устроили - разве что есть смысл немного увеличить количество процессов, обрабатывающих потоки запросов мониторинга (по умолчанию: 5):



Запускаем или перезапускаем сервис "шлюза":


Удостоверяемся, что сервис запущен успешно и в журнале событий нет сообщений о критичных сбоях (пример для Systemd):



Также проверяем, слушает ли сервис "шлюза" заданные сетевые интерфейс и порт:



Серверу мониторинга достаточно лишь указать точку входа для обращений к "шлюзу" и количество одновременно обслуживаемых потоков запросов:



Применение параметров требует перезапуска сервиса сервера мониторинга:


Настройка клиента мониторинга, на примере "WildFly".

По умолчанию подсистема JMX в "WildFly" отвечает на запросы только с "локальной сетевой петли". Для доступа к JMX снаружи придётся это явно разрешить - например так:



Применение изменений такого рода потребует перезапуска "WildFly":


Как вариант, вместо внесения правок в конфигурационный файл можно запускать "WildFly" с параметром "-Djboss.bind.address.management=0.0.0.0".

Кроме разрешения доступа извне потребуется завести соответствующего пользователя ("zbx-jmx", например), от имени которого "Zabbix Java Gateway" будет аутентифицироваться при подключении к JMX-интерфейсу:



Есть смысл сразу проверить, доступен ли порт, выделенный для удалённого мониторинга WildFly-сервера, со стороны сервера мониторинга:



Наверняка подключение к "WildFly" будет блокироваться защитным экраном несущей системы, и его придётся явно разрешить, например так (помним о необходимости как-то сохранять Iptables-правила):


Решение проблемы поддержки протокола JMX-соединений.

Первое, что нужно делать, когда что-то не работает - идти читать журналы событий:


Возможные следующие сообщения об ошибках означают, что "Zabbix Java Gateway" не имеет соответствующих библиотек для работы с указанным протоколом:


Это легко исправить, взяв таковые из дистрибутива "JBoss AS/WildFly", который мы собираемся мониторить.

Всё, что требуется "Zabbix Java Gateway", ожидается им в его домашней директории, путь к которой можно подсмотреть в стартовом скрипте:



Попросту находим все Java-библиотеки поддержки клиентских протоколов и укладываем их в домашнюю директорию "Zabbix Java Gateway":


Перезапускаем сервис, чтобы он загрузил все обнаруженные библиотеки:


Костыль перезагрузки.

Как я выше отмечал, служба "Zabbix Java Gateway" очевидно ещё не доросла до уровня стабильно работающего приложения. Иногда она попросту перестаёт работать. Не зависает в привычном понимании этого слова, не останавливается - просто перестаёт отвечать на запросы, с периодичностью в одну-две недели. Среди нас не обнаружилось специалистов по Java-приложениям, и лучшее решение, которое мы смогли найти - перезапуск пару раз в день с плывущим графиком:



Нюанс указания на JMX-интерфейс в GUI "Zabbix Server".

Как я упоминал выше, сервис "Zabbix Java Gateway" с точки зрения пользователя представляет собой один из системных компонентов, прозрачно обрабатывающих специфичные запросы к подсистемам вроде "Zabbix Agent", SNMP или IPMI. Вспомогательного сервиса "шлюза" на пути к JMX-интерфейсам узлов мониторинга для пользователя будто не существует, а в параметрах "IP", "FQDN" и "TCP port" описания узла сети (в web-интерфейсе "Zabbix Server") следует указывать данные точки приёма JMX-запросов на стороне объекта мониторинга.