Новые возможности мониторинга 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 для него должен выглядеть так:


    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’а клиент может получать различные метрики этого объекта, а также вызывать публичные методы.


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



    Любое приложение на платформе 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


    Но на самом деле не всё так страшно.

    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.


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


    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.

    Если мы сейчас просто возьмём стандартный шаблон "Template App Generic Java JMX" и прилинкуем его к хосту, то наверняка получим ошибку:


    $ tail -f /tmp/zabbix_java.log


    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}



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


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

    И снова ошибка.

    Что на этот раз?
    “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:


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


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


    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 <JAVA_GATEWAY_HOST> <JAVA_GATEWAY_PORT> <JMX_SERVER> <JMX_PORT> <JMX_ENDPOINT> <KEY>"
        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'



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


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


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


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

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


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


    1. И всего лишь один прототип:


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


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


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


    Итог


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


    Stay tuned!


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



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


    • +20
    • 8,9k
    • 7
    Zabbix 92,77
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 7
    • 0
      Почему snmp-builder-а нет в апстриме?
      • +2

        Эх, разрабы заббикса как не предполагали, что на одном сервере могут работать несколько джава-приложений, так и не предполагают. Попробуйте промониторить, скажем память нескольких jvm через jmx. Получите дублирование ключей итемов. Приходится использовать хак с пробелами в названии ключей.

        • 0
          Это не особенность jmx мониторинга, а ключей в целом.
          • 0
            Да, понимаю. Я о том, что новые возможности, это конечно хорошо! Но что делать со старыми ограничениями? Понятно, что ключи, на то они и ключи, чтоб быть уникальными (в пределах хоста), но хотелось бы иметь возможность добавлять им уникальности не только добавлением пробелов (например, jmx-endpoint использовать как параметр ключа). Это ограничение приводит к тому, что, использовать JMX, для мониторинга базовых параметров JVM, например, когда на сервере несколько десятков микросервисов, очень не удобно. Свои MBean-ны внутри микросервисов можно называть уникально и мониторить их свойства без проблем.
            Почти все, конечно можно обойти, благо, например, мониторить память и процессор можно и «снаружи» JVM через итемы самого Zabbix-agent-а.
        • 0
          Хорошо что есть jolokia которая превращает RMI в HTTP и не ограничивает возможности мониторинга/алертинга
          • 0
            Спасибо за статью и возможность конфигурировать JMX endpoint.

            В standalone режиме данная статья подойдет отлично, но вот как быть если нужно мониторить Jboss EAP 6 в domain режиме. Предположим есть несколько server-groups и у каждой server-group порядка 6-10 Jboss instance?

            На сколько я понял один Zabbix Host может мониторить только 1 JMX endpoint.

            Спасибо.
            • 0
              JMX endpoint конфигурируется per-item, так что можно использовать сколько хочется endpoints в рамках одного хоста.

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

            Самое читаемое