Zabbix Documentation 4.4
Sidebar
Table of Contents
5 Java gateway
Обзор
Java gateway принимает входящие подключения от Zabbix сервера или прокси и может быть использован только как «пассивный прокси». Но в отличии от Zabbix прокси, Java gateway может использоваться с Zabbix прокси (тогда как один Zabbix прокси не может работать через другой Zabbix прокси). Доступ к каждому Java gateway настраивается непосредственно в файле конфигурации Zabbix сервера или прокси, таким образом только один Java gateway может быть настроен на Zabbix сервере или Zabbix прокси. Если у узла сети есть элементы данных типа JMX агент и элементы данных других типов, то только элементы данных JMX агент будут запрошены через Java gateway.
Когда элемент данных должен быть обновлен через Java gateway, Zabbix сервер или прокси подключается к Java gateway и запрашивает значение, Java gateway в свою очередь запрашивает это значение и возвращает серверу или прокси. Таким образом, Java gateway никакие значения не кэширует.
У Zabbix сервера и прокси есть специальный тип процессов, которые подключается к Java gateway, их количество настраивается опцией StartJavaPollers. Внутренне, Java gateway запускается несколькими потоками, настраиваемыми опцией START_POLLERS. На стороне сервера, если соединение занимает более чем Timeout секунд, оно будет завершено, но Java gateway может оставаться занят получением значения JMX счетчика. Чтобы решить эту проблему, Java gateway начиная с Zabbix 2.0.15, Zabbix 2.2.10 и Zabbix 2.4.5 поддерживают опцию TIMEOUT, позволяющую указать время ожидания сетевых операций JMX.
Zabbix сервер и прокси будут пытаться максимально объединить запросы к одной цели JMX (зависит от интервалов обновления элементов данных) и отправлять их в Java gateway за одно подключение для лучшей производительности.
Рекомендуется выставить значение StartJavaPollers меньшим или равным START_POLLERS, в противном случае могут возникнуть ситуации, когда потоков Java gateway может не хватить для обслуживания входящих запросов; в этом случае Java gateway воспользуется ThreadPoolExecutor.CallerRunsPolicy, что означает, что основной поток будет обслуживать входящий запрос и временно не сможет принимать любые новые запросы.
Получение Java gateway
Вы можете установить Java gateway как из исходных кодов, так и из пакетов, которые можно загрузить с Zabbix веб-сайта.
Используя приведённые ниже ссылки вы можете получить доступ к информации о том как получить и запустить Zabbix Java gateway, как настроить Zabbix сервер (или Zabbix прокси) на использование Zabbix Java gateway для JMX мониторинга, и как настроить элементы данных Zabbix в Zabbix веб-интерфейсе, которые соответствуют определенным счётчикам JMX.
Новые возможности мониторинга Java приложений в Zabbix 3.4
Что случилось?
Вышел долгожданный релиз Zabbix 3.4, который принёс много полезных улучшений, среди которых оказались настраиваемые JMX endpoints и гибкое обнаружение MBean’ов.
Это так круто, да?
Если вы используете Zabbix и вам требуется мониторить Java приложения, то да — это может сильно облегчить вам жизнь, потому что раньше приходилось прибегать к различным ухищрениям, а теперь всё работает, как говорится, “из коробки”.
А что не так с этими JMX endpoints?
Нативный мониторинг Java приложений через JMX появился в Zabbix давно — начиная с версии 2.0 — и с тех пор этот функционал улучшается от версии к версии. Но так вышло, что в предыдущих релизах JMX endpoint был жёстко зашит в код Zabbix Java Gateway совершенно наивным образом.
Как выяснилось, в мире Java существует масса софта, который использует иные endpoints, а старые версии Zabbix не позволяли менять этот параметр. Для многих пользователей это стало реальной проблемой. Например, популярный сервер приложений JBoss EAP 6 использует для удалённого доступа к JMX свой протокол JBoss Remoting вместо RMI и JMXServiceURL для него должен выглядеть так:
А, например, WebSphere 8.5 использует RMI поверх IIOP (а не JRMP) и для него JMXServiceURL должен быть таким:
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’а клиент может получать различные метрики этого объекта, а также вызывать публичные методы.
Схематично взаимодействие компонентов можно изобразить так:
Любое приложение на платформе Java SE “из коробки” имеет возможности для его мониторинга: RMI коннектор автоматически делает доступным ваше Java приложение для удалённого управления и мониторинга. Достаточно лишь запустить приложение с нужными параметрами, и JMX-клиенты (а Zabbix Java Gateway — это JMX-клиент) уже смогут подключаться к нему удалённо и получать нужные метрики.
Чтобы указать JMX-клиенту конкретное приложение, к которому вы хотите подключиться, используется специальный адрес, который называется JMX endpoint (он же JMXServiceURL). Если говорить строже, то это адрес коннектор-сервера JMX API. Формат этого адреса определяется RFC 2609 и RFC 3111. В общем случае он выглядит так:
Где «service:jmx:» — константа.
protocol — это транспортный протокол (один из многих: RMI, JMXMP, etc), используемый для подключения к коннектор-серверу.
sap — адрес, по которому коннектор-сервер может быть найден. Задаётся в таком формате (это подмножество синтаксиса, определённого в RFC 2609):
host[:port] — ipv4 адрес хоста (или ipv6, заключённый в квадратные скобки) и необязательный (в зависимости от протокола) номер порта.
url-path — необязательный URL (обязательность зависит от протокола).
Лучше всего разобраться с этим на примере. Часто можно встретить такой JMX endpoint, вид которого некоторых может ввести в ступор:
Но на самом деле не всё так страшно.
host — это целевой хост, где запущено наше приложение.
port1 — это порт RMI-сервера, к которому мы хотим подключиться.
а port2 — это порт RMI registry (каталог, где регистрируются RMI-серверы). По умолчанию: 1099.
Если знать о том, что RMI-реестр выдаёт адрес и порт RMI-сервера по запросу клиента, то становится понятно, что первая часть здесь лишняя. Таким образом адрес можно сократить до такого вида:
url-path часть означает буквально следующее: возьми ту часть URL, которая следует сразу за /jndi/ и выполни по этому адресу JNDI-запрос в RMI registry, чтобы получить информацию об RMI-сервере. Реестр вернёт в ответ его хост и порт.
Следует отметить, что порт в таком случае генерируется случайным образом и могут возникнуть проблемы с настройкой файрвола. В таких случаях и используют предыдущий вариант записи JMX endpoint’а, потому что он позволяет явно указать порт.
Если вам хотелось бы глубже разобраться в JMX, то рекомендуем обратиться к официальной документации Oracle.
Может лучше на практике?
Нет ничего проще 🙂 Давайте для примера попробуем настроить мониторинг JBoss EAP 6.4.
Для начала сделаем несколько предположений:
Сделаем несколько простых настроек в zabbix_server.conf:
И в конфиге zabbix_java/settings.sh (или zabbix_java_gateway.conf):
Проверьте, что JBoss слушает свой стандартный management port:
Теперь давайте создадим в Zabbix хост с JMX интерфейсом 127.0.0.1:9999.
Если мы сейчас просто возьмём стандартный шаблон «Template App Generic Java JMX» и прилинкуем его к хосту, то наверняка получим ошибку:
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:
Обновим конфигурационный кэш:
И снова ошибка.
Что на этот раз?
“Unsupported protocol: remoting-jmx” означает, что Java Gateway не умеет работать с указанным протоколом. Что ж, давайте его научим. В этом нам поможет совет из статьи «JBoss EAP 6 monitoring using remoting-jmx and Zabbix».
/needed_modules.txt со следующим содержимым:
Таким образом, Java Gateway будет иметь все необходимые модули для работы с jmx-remoting. Остаётся лишь перезапустить Java Gateway, немного подождать и, если вы всё сделали правильно, увидеть, что заветные данные начали поступать в Zabbix:
А что там с JMX обнаружением?
JMX обнаружение появилось в Zabbix одновременно с появлением нативной поддержки мониторинга Java приложений через JMX. За эту функцию отвечает недокументированный (на тот момент) ключ 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 в запрос и поправим удаление заголовка из ответа:
Теперь мы с лёгкостью можем посмотреть, что возвращает нам шлюз в ответ на наши запросы:
То что нужно!
Если бы нам требовалась, допустим, всего пара метрик, то мы могли бы обнаружить все gc и создать на каждую метрику по прототипу.
Кстати, о макросах. При обнаружении MBean’ов макросы генерируются динамически на основе свойств MBean’ов (таких как type и name).
Обратите внимание на эту проблему при использовании динамических макросов: https://support.zabbix.com/browse/ZBX-12705
Но, допустим, мы хотим создать все доступные числовые метрики по сборщикам мусора.
Вот таким нехитрым образом можно замониторить любое Java приложение. Дерзайте! 🙂
У меня сейчас нет возможности обновиться на Zabbix 3.4, как мне быть?
Сообщество придумало множество способов как обойти эту проблему. Если у вас пока нет возможности обновиться на эту версию, то вот вам ссылки: раз и два.
Благодаря новым реализованным возможностям мониторинг Java приложений в Zabbix перестал быть болью. Напротив, с каждой новой версией это становится всё более простым и приятным занятием 🙂 Будем стараться радовать вас и дальше!
Zabbix + JMX ( Мониторинг состояния Java-приложений по протоколу JMX. )
20 сентября 2018 (обновлено 14 декабря 2018)
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 Java Gateway».
По состоянию на 2018-й год инструментарий мониторинга Java-приложений в «Zabbix» явно не выведен на уровень полной готовности, так что в публичных репозиториях Linux-ов его пока нет. Достаточно просто подключить репозиторий разработчиков и загрузить необходимый пакет ПО оттуда:
Ради одного пакета можно не подключаться к репозиторию, а скачать его напрямую (ссылка на ПО для «Linux Ubuntu»), но тогда потеряется возможность его простого обновления.
Настройка спарки «Zabbix Server» и «Zabbix Java Gateway».
Запускаем или перезапускаем сервис «шлюза»:
Удостоверяемся, что сервис запущен успешно и в журнале событий нет сообщений о критичных сбоях (пример для Systemd):
Также проверяем, слушает ли сервис «шлюза» заданные сетевые интерфейс и порт:
Серверу мониторинга достаточно лишь указать точку входа для обращений к «шлюзу» и количество одновременно обслуживаемых потоков запросов:
Применение параметров требует перезапуска сервиса сервера мониторинга:
Настройка клиента мониторинга, на примере «WildFly».
Применение изменений такого рода потребует перезапуска «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»:
Перезапускаем сервис, чтобы он загрузил все обнаруженные библиотеки:
Нюанс указания на JMX-интерфейс в GUI «Zabbix Server».
Как я упоминал выше, сервис «Zabbix Java Gateway» с точки зрения пользователя представляет собой один из системных компонентов, прозрачно обрабатывающих специфичные запросы к подсистемам вроде «Zabbix Agent», SNMP или IPMI. Вспомогательного сервиса «шлюза» на пути к JMX-интерфейсам узлов мониторинга для пользователя будто не существует, а в параметрах «IP», «FQDN» и «TCP port» описания узла сети (в web-интерфейсе «Zabbix Server») следует указывать данные точки приёма JMX-запросов на стороне объекта мониторинга.
[ уже посетило: 6710 / +2 ] [ интересно! / нет ]
Поблагодарить автора 
( сделайте свой денежный вклад в хорошее настроение )
Zabbix Documentation 2.2
Sidebar
Table of Contents
5 Java gateway
Обзор
Java gateway принимает входящие подключения от Zabbix сервера или прокси и может быть использован только как «пассивный прокси». Но в отличии от Zabbix прокси, Java gateway может использоваться с Zabbix прокси (тогда как один Zabbix прокси не может работать через другой Zabbix прокси). Доступ к каждому Java gateway настраивается непосредственно в файле конфигурации Zabbix сервера или прокси, таким образом только один Java gateway может быть настроен на Zabbix сервере или Zabbix прокси. Если у узла сети есть элементы данных типа JMX агент и элементы данных других типов, то только элементы данных JMX агент будут запрошены через Java gateway.
Когда элемент данных должен быть обновлен через Java gateway, Zabbix сервер или прокси подключается к Java gateway и запрашивает значение, Java gateway в свою очередь запрашивает это значение и возвращает серверу или прокси. Таким образом, Java gateway никакие значения не кэширует.
У Zabbix сервера и прокси есть специальный тип процессов, которые подключается к Java gateway, их количество настраивается опцией StartJavaPollers. Внутренне, Java gateway запускается несколькими потоками, настраиваемыми опцией START_POLLERS. На стороне сервера, если соединение занимает более чем Timeout секунд, оно будет завершено, но Java gateway может оставаться занят получением значения JMX счетчика. Чтобы решить эту проблему, Java gateway начиная с Zabbix 2.0.15 и Zabbix 2.2.10 поддерживает опцию TIMEOUT, позволяющую указать время ожидания сетевых операций JMX.
Zabbix сервер и прокси будут пытаться максимально объединить запросы к одной цели JMX (зависит от интервалов обновления элементов данных) и отправлять их в Java Gateway за одно подключение для лучшей производительности.
Рекомендуется выставить значение StartJavaPollers меньшим или равным чем START_POLLERS, в противном случае могут возникнуть ситуации, когда потоков Java gateway может не хватить для обслуживания входящих запросов.
Разделы ниже рассказывают о том как получить и запустить Zabbix Java gateway, как настроить Zabbix сервер (или Zabbix прокси) для использования Zabbix Java gateway в мониторинге JMX, и как настроить элементы данных Zabbix в Zabbix веб-интерфейсе, которые соответствуют конкретным JMX счетчикам.
5.1 Получение Java gateway
5.1.1 Загрузка с веб-сайта Zabbix
Пакеты Zabbix Java gateway (для RHEL, Debian, Ubuntu) доступны для загрузки на странице http://www.zabbix.com/download.php.
5.1.2 Сборка исходных кодов
5.2 Обзор файлов из поставки Java gateway
Собственно JAR файл Java gateway.
Зависимости Java gateway: Logback, SLF4J, и библиотека Android JSON (Примечание: до Zabbix 2.2.5 использовалась библиотека JSON.org).
Файлы конфигурации для Logback.
Скрипты для удобства запуска и остановки Java gateway.
Файл конфигурации, который используется вышеупомянутыми скриптами запуска и остановки.
5.3 Настройка и запуск Java gateway
По умолчанию, Java gateway слушает порт 10052. Если вы планируете работу Java gateway на другом порту, то вы можете указать его в скрипте settings.sh. Смотрите описание файла конфигурации Java gateway для получения сведений о том как указать эту и другие опции.
Выполнив настройки, вы можете запустить Java gateway, выполнив скрипт запуска:
Точно так же, если вам более не требуется Java gateway, выполните скрипт завершения работы для остановки Java gateway:
Обратите внимание, что в отличии от сервера и прокси, Java gateway легок и не требует наличия базы данных.
5.4 Настройка сервера для использования с Java gateway
Теперь, когда Java gateway запущен, вы должны указать Zabbix серверу где искать Zabbix Java gateway. Чтобы это сделать, укажите параметры JavaGateway и JavaGatewayPort в файле конфигурации сервера. Если же узел сети на котором работает JMX приложение наблюдается через Zabbix прокси, то параметры соединения указываются в файле конфигурации прокси.
По умолчанию, сервер не запускает процессы связанные с мониторингом JMX. Если же вы хотите использовать этот тип мониторинга, то вам нужно указать количество экземпляров Java поллеров. Вы можете это сделать таким же способом как и изменение количества поллеров и трапперов.
Не забудьте перезапустить сервер или прокси после того как закончите изменение настроек.
5.5 Отладка Java gateway
В случае возникновения каких-либо проблем с Java gateway или в случае, если сообщение об ошибке элемента данных в веб-интерфейсе недостаточно информативно, вы можете обратиться к файлу журнала Java gateway.
По умолчанию, Java gateway записывает журнал в файл /tmp/zabbix_java.log с уровнем журналирования «инфо». Бывает, что этой информации недостаточно и требуется информация уровня журналирования «отладка». Чтобы увеличить уровень журналирования, отредактируйте файл lib/logback.xml и измените атрибут «level» тэга на «debug»:
Если вы хотите записывать журнал в другой файл или в совершенно другую среду такую как база данных, настройте файл logback.xml в соответствии с вашими потребностями. Обратитесь к Руководству по Logback для получения более подробных сведений.
Иногда для отладки полезно запустить Java gateway как консольное приложение, а не как демон. Чтобы это сделать, закомментируйте переменную PID_FILE в settings.sh. Если PID_FILE не указан, скрипт startup.sh запускает Java gateway как консольное приложение, при этом Logback использует файл lib/logback-console.xml, который не только выводит журнал в консоль, но и имеет уровень журналирования «debug».
В заключение, отметим, поскольку Java gateway использует SLF4J для журналирования, вы можете заменить Logback выбранным вами фреймворком, поместим соответствующий JAR файл в каталог lib. Обратитесь к Руководство по SLF4J для получения более подробных сведений.
