Install and Configure JMX using Zabbix Java Gateway

With the introduction of Zabbix 2.0 & above, the ability to monitor JMX counters without deploying additional software has been introduced in the form of a daemon called “Zabbix Java Gateway“. The most common use of JMX is monitoring thread counts and memory usage of any Java enabled application via the resource objects called MBeans (Managed Beans). SeeВ wikiВ for full explanation.

Zabbix Java Gateway can be installed alongside Zabbix Server or as a standalone server. For the purpose of this post, all Zabbix components will be installed on a single server

Step 1: InstallВ Zabbix Java Gateway

I have documented the installation of zabbix java gateway in a previous post. ClickВ Installing Zabbix 2.0 package from EPEL on CentOS 6.4В for full installation guide

Step 2: ConfigureВ Zabbix Java Gateway

After installing the zabbix java gateway, we need to configure it for use by telling the zabbix server where to find it.

– Log into zabbix using Putty. Edit the config file “zabbix_server.conf” using the command “ vi /etc/zabbix/zabbix_server.conf “. Un-comment the following lines (JavaGateway, JavaGatewayPort & StartJavaPollers) and enter the В JavaGateway IP address or Hostname, Leave port as default or change it to desired port for security and enter number of pre-forked instances of Java pollers

Note: if you are monitoring servers via zabbix proxy, then the above configuration should be done on the zabbix proxy config file

– Restart zabbix server service

[code language=”js”]# service zabbix-server restart[/code]

Step 3: Add JMX interfaces for JMX communication

– On zabbix, click on host (server) running the java application. Under JMX interfaces, click the Add… button to add the IP address, DNS name and Port used by the java application. Save changes

Step 4: Add JMX agent item

After setting up and configuring the zabbix java gateway, next is to add a new JMX agent item you desire to monitor. For the purpose of showing you how this works, I will be monitoring the memory used by Java VM that runs the JConsole. I have already installed JConsole on my machine (see Installing JConsole for windows). At this stage I am assuming that you are already familiar with how to create a zabbix item and assign it to a server or a template.

1. First before you can monitor a Java application via JMX, you will need the following information “ & “

– Launch jconsole by typing “jconsole” from command prompt. Select “Remote Process“, enter “localhost:0” or “ ” whereВ host isВ localhost or remote serverВ and the portВ . Click Connect

– Click on MBeans tab, expand java.lang and click on Memory. Note the ObjectName value

– Expand Attributes and click on HeapMemoryUsage. Note the attribute name. You will also notice at the top the values of the different memory checks we will be monitoring

2. Create JMX Item

– See screenshot below to setup monitor for used HeapMemoryUsage . Remember to enter the KEY correctly and also select appropriate JMX Host Interface with correct Port ifВ you have more than one JMX interface/port added. This happens when you have more than one Java enabled application on same server with different port

After saving newly created item, Go to Monitoring > Latest Data, select the server this item was created on and check if it’s started receiving updates by clicking on the Graph for the item. I have screenshots of one of my LIVE machines been monitored:

Graph:

JConsole:

As seen in both diagrams, I have marked out 3 points for comparison and you will notice that the values are same which means we are now able to use Zabbix JMX to monitor Java applications

Any questions, please feel free to ask рџ™‚

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» был создан инструмент «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-запросов на стороне объекта мониторинга.

[ уже посетило: 4843 / +1 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Мониторинг Java приложений в Zabbix, кастомизируем JavaGateway для JMX LLD

Вступление

&nbsp&nbsp&nbsp&nbspВ данной статье я расскажу, как можно немного кастомизировать Zabbix JavaGateway для наиболее удобного низко уровневого обнаружения JMX метрик. Здесь github.com/mfocuz/zabbix_plugins/tree/master/jmx_discovery можно взять патч на версию 2.0.11 и посмотреть примеры external скриптов. Но обо всем по порядку.

&nbsp&nbsp&nbsp&nbspС версии 2.0 в Zabbix появилась нативная поддержка мониторинга Java приложений через JMX. Но возможно не все знают, что кроме сбора метрик мы можем их также дискаверить в Zabbix из коробки. В документации этот момент либо пропустили, либо посчитали фичу несовсем готовой(хотя может я просто не нашел этого в доке?), но эта фича там есть, и, на мой взляд, она действительно не совсем готова. Хотя я не уверен что она вообще работает, до тестирования не дошло.

&nbsp&nbsp&nbsp&nbspВ исходниках zabbix_javagw в классе JMXItemChecker.java для версии 2.0.11 строка 157 и далее:

&nbsp&nbsp&nbsp&nbspКак видно из кода, если в конфигурации дискавери правил задать ключ с именем “jmx.discovery”, то отработает обнаружение, которое вернет все атрибуты по всем найденым mbeans.
&nbsp&nbsp&nbsp&nbspЗдесь в первую очередь хочется отметить, что в таком запросе нет особой необходимости. Во-первых, подобный запрос работает не совсем быстро, потому что запрос на атрибуты каждого мбина проходит отдельным запросом, а бинов может быть достаточно много. Во вторых, ключ дискавери правила является уникальным значением в Zabbix, а это значит, что используя jmx.discovery мы можем создать одно единственное дискавери правило для JMX метрик в пределах одного хоста, что для большинства задач совершенно не подходит. Ну и в третьих, атрибуты для каждого java mbean как правило не меняются, тоесть их кол-во и назначение в пределах одного бина постоянно. Это значит что сами атрибуты лучше задать в item прототипах и часть кода, которая собственно и является самым тормозом:

становится не нужна. А вот кол-во mbeans может быть переменным. Например Oracle Coherence создает определенное кол-во бинов под каждую ноду в кластере. В результате мы имеем бины, название которых отличается только по nodeId. И например при рестарте кластера все nodeId меняются. То есть Java метрики имеют динамические имена mbeans. Вот тут мы и используем LLD, но:

1. Нам нужны только сами mbeans, без атрибутов (можно и их обнаружить, но имхо это лишне).
2. Нам важно иметь возможность создавать несколько дискавери правил на один хост.
3. Нам нужна возможность кодировать разнообразную логику для дискавери правил.

&nbsp&nbsp&nbsp&nbspНе так давно появилась одна статья о JMX дискавери www.zabbix.org/wiki/Docs/howto/jmx_discovery. Последний год я использовал похожее решение. В краце: суть этого решени в запуске .jar файла как external скрипта. Огромный его минус в том, что Java не рассчитана на многократный запуск, как это обычно делается для интерпретируемых языков типа python или perl. Этот минус делает решение практически не рабочим. Скажем, на виртуалке с 2мя корами для запуска порядка 20 дискавери правил загрузка CPU уходила полку, в результате external чеки просто отваливались по таймауту. На железках где было по 8кор вроде работало исправно. Но всеравно, запуск пачки JVM раз в N минут решение не красивое и можно рассматривать только как костыль.

Как будет работать новая функциональность

&nbsp&nbsp&nbsp&nbspДля начала рассмотрим, как взаимодействуют Zabbix сервер и JavaGateway. Для сбора JMX метрик Zabbix сервер коннектиться к JavaGateway по TCP, после чего делает запрос на нужные данные по Zabbix протоколу. На оф сайте есть общее описание протокола, опишу его чуть более подроно т.к. он нам понадобиться для LLD.
Сообщение к серверу и ответ от него состоит из 3х частей:

1. Заголовок ZBXD\1
2. Длина сообщения
3. Сообщение в формате JSON.

Выглядит примерно так:

&nbsp&nbsp&nbsp&nbspМне хотелось сделать минимум изменений в коде Zabbix, поэтому код Zabbix сервера мы не трогаем, в схеме выше мы заменяем Zabbix server на externalscript, который будет делать такое же соединение. А в JavaGateway коде добавим нужную нам фун-ть. И теперь общение с JavaGateway для LLD выглядит вот так:

То есть добавилось поле regexp и новый вид request = “java jmx lld”.

Меняем JavaGateway код

&nbsp&nbsp&nbsp&nbspЧто же нужно допилить чтобы JMX дискавери стал удобным и быстрым? По задумке разработчиков в JavaGateway есть два возможных request запроса, их можно найти в коде ItemChecker.java, это константы JSON_REQUEST_INTERNAL для сбора пары внутренних JavaGateway метрик, и JSON_REQUEST_JMX — который является основным запросом и служит для сбора JMX метрик. В коде SocketProcessor.java видим:

&nbsp&nbsp&nbsp&nbspТо есть тут определяется какого типа будет checker. Мы добавим 3й вид запроса — JSON_JMX_LLD. И соот-но еще одно условия для нашего запроса в SocketProcessor.java:

&nbsp&nbsp&nbsp&nbspТеперь, когда сервер получит запрос на JSON_JMX_LLD, будет создан экземпляр класса JMXItemDiscoverer и вызван метод getValues. Осталось добавить класс JMXItemDiscoverer, который сделает дискавери правило так, как нам было бы удобно, а именно — сделает запрос на все имеющиеся бины и на выходе будет возвращать список бинов по заданному регэкспу. Код нового класса можно увидить в патче.

Настраиваем новый Java gateway

&nbsp&nbsp&nbsp&nbspЕсть два варианта, можно подменить сам JavaGateway, а можно поднять еще один, который будет работать только для LLD. Если меням gateway на PRO, то:
&nbsp&nbsp&nbsp&nbsp1.На стороне Zabbix нужно изменить только JavaGateway. По ссылке в начале статьи можно найти патч на zabbix java gateway версии 2.0.11. Я немного полазил diff’ом по коду 2.2 и 2.0.11, так вот java gateway там не сильно отличается, поэтому думаю при базовом знании Java будет не сложно перенести патч и на последнюю версию.
&nbsp&nbsp&nbsp&nbsp2.Далее накатываем патч и собираем JavaGateway под установленную версию Java.
&nbsp&nbsp&nbsp&nbsp3.Получившийся .jar подкладываем на место старого, все остальные файлы java gateway включая конфиг, либы и прочее оставляем как есть.
&nbsp&nbsp&nbsp&nbsp4. Стартуем. Получаем тот же Java gateway, но теперь он умеет обрабаывать еще один вид запросов.
&nbsp&nbsp&nbsp&nbsp5. Для самих запросов пишем скрипт который будет цепляться к серверу по TCP и собственно делать сам запрос. Я набросал простой модуль JMXDiscovery.pm для Perl, чтобы было проще написать дискавери скрипт плюс пример дискавери скриптаjmx_discovery.pl и использования модуля.(можно найти там же по ссылке в начале).
&nbsp&nbsp&nbsp&nbsp6. Ну и наконец создаем дискавери правила, в типе указываем externalscript. Параметры передаваемы скрипту будут обеспечивать уникальность ключа, что и позволит создать любое кол-во правил.

&nbsp&nbsp&nbsp&nbspЕсли же хочется поднять отдельный сервер для LLD, то п.3 пропускаем и после сборки вместе с патчем просто ставаим JavaGateway отдельным сервисом.