В этой статье я рассмотрю мониторинг работы java-приложения в системе мониторинга Zabbix.
В официальной документации Zabbix это называется JMX мониторинг.
Управленческие расширения Java (англ. Java Management Extensions, JMX) — технология Java, предназначенная для контроля и управления приложениями, системными объектами, устройствами (например, принтерами) и компьютерными сетями (Википедия).
Основной упор я сделаю на использовании SSL при установлении связи сервера с клиентом, т.к. этот вопрос в официальной документации не рассматривается должным образом, а 99% реализаций этого мониторинга применяются (почему-то) без использования SSL.
#Настройка на стороне сервера
Согласно инструкции Zabbix, устанавливаем на стороне сервера Zabbix Java gateway. Создаю каталог для сертификатов и открываю файл конфигурации:
mkdir /etc/zabbix/zabbix_java/
nano /etc/zabbix/zabbix_java_gateway.conf
В конце прописываю строки:
JAVA_OPTIONS="$JAVA_OPTIONS -Djava.security.debug=ssl -Djavax.net.debug=all -Djavax.net.ssl.keyStore=/etc/zabbix/zabbix_java/.keystore -Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStore=/etc/zabbix/zabbix_java/.certstore -Djavax.net.ssl.trustStorePassword=password"
Обращаю внимание на кавычку в конце, она же есть и почти в начале, перед $JAVA_OPTIONS.
Zabbix-сервер тоже надо подготовить, расскомментировать нужные опции:
nano /etc/zabbix/zabbix_server.conf JavaGateway=127.0.0.1 JavaGatewayPort=10052 StartJavaPollers=5
Zabbix Java gateway находится у меня вместе с Zabbix-сервер, поэтому JavaGateway имеет адрес 127.0.0.1
Переходим в каталог /etc/zabbix/zabbix_java/ и создаём ключ и сертификат.
keytool -genkeypair -dname "CN = server.name, OU = JavaSoft, O = Sun, L = OVH, S = France, C = EU" \ -alias server.name \ -keyalg RSA \ -keysize 1024 \ -validity 3650 \ -keystore .keystore \ -storepass password
Вместо CN = server.name можете указать имея своего домена (даже если оно не настоящее; в данном случае будет работать).
Немного моих пояснений, хотя везде всё уже написано, но всё же. Встречается ключ -genkeypair и -genkey. Это одно и то же. Когда-то версия keytool сменилась и зачем-то поменяли имя ключа, хотя поддержка есть обоих ключей.
По параметрам ключей и всего и вся есть официальная дока от Oracle по keytool — https://docs.oracle.com/javase/1.5.0/docs/tooldocs/solaris/keytool.html. Советую больше опираться на неё для начала, чем на короткие выдержки.
Извлекаем открытый ключ, он же будет сертификат:
keytool -export -alias server.name-keystore .keystore -file server.name.cer -storepass password
Этот сертификат (server.name.cer )надо будет передать клиенту и выполнить на его стороне команду:
keytool -import -alias server.name -file server.name.cer -keystore .certstore -storepass password
Эта команда добавит сертификат сервера в доверенное хранилище на стороне клиента.
#Настройка на стороне клиента
Создаём ключ и сертификат аналогично как на сервере, только имена меняем. Создаём закрытый ключ:
keytool -genkeypair -dname "CN = client1 , OU = JavaSoft, O = Sun, L = OVH, S = France, C = EU" \ -alias client1 \ -keyalg RSA \ -keysize 1024 \ -validity 3650 \ -keystore .keystore \ -storepass password
И так же аналогично, как на сервере, извлекаем открытый ключ и он же будет сертификатом клиента:
keytool -export -alias client1 -keystore .keystore -file client1.cer -storepass password
Этот сертификат надо переписать на сервер и там добавить в доверенное хранилище. На сервере надо выполнить такую команду:
keytool -import -alias client1 -file client1.cer -keystore .certstore -storepass password
Доверенное хранилище в моём примере имеет имя .certstore (скрытый файл). В примерах с других сайтов оно называется .truststore. Это не принципиально. Главное, указать правильное имя в конфигурационном файле.
Конфигурационный файл на стороне клиента у меня выглядит вот так:
#!/bin/sh java \ -Djava.rmi.server.hostname=22.222.22.33 \ -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=10053 \ -Dcom.sun.management.jmxremote.authenticate=true \ -Dcom.sun.management.jmxremote.password.file=jmxremote.password \ -Dcom.sun.management.jmxremote.access.file=jmxremote.access \ -Dcom.sun.management.jmxremote.ssl=true \ -Djavax.net.debug=ssl,handshake \ -Djava.security.debug=ssl \ -Djavax.net.ssl.keyStore=.keystore \ -Djavax.net.ssl.keyStorePassword=password \ -Djavax.net.ssl.trustStore=.certstore \ -Djavax.net.ssl.trustStorePassword=password \ -Djava.net.preferIPv4Stack=true\ -jar server.jar $1 $2
Эта скрипт, который запускает программу на стороне клиента. У меня включена аутентификация по паролю jmxremote.authenticate. Если у вас её нет, то выставите jmxremote.authenticate=false и удалите строки с jmxremote.authenticate и .jmxremote.access.file.
#Как это работает
На стороне сервера после создания ключей и добавления сертификата в доверенное хранилище надо обязательно перезапустить zabbix-java-gateway
service zabbix-java-gateway restart
Рекомендую посмотреть после этого service zabbix-java-gateway status. Даже если всё запустилось успешно, то это не факт, что всё работает корректно. После исполнения команды может быть информация и тех ключах конфигурации, которые не сработали.
В веб интерфейсе Zabbix добавляется хост для мониторинга, где указывается порт в моём случае 10053, т.к. — Dcom.sun.management.jmxremote.port=10053 \
На стороне клиента запускается само приложение java. В идеале всё должно заработать. Не в идеале может быть множество вариантов причин из-за которых что-то пошло не так и это я опишу в отдельной заметке.
Отмечу лишь, что данная генерацию ключей и конфиги — проверенные и рабочие. Zabbix-server 4.2.0, java version «1.7.0_261» (Open JDK). На стороне клиента java version «1.8.0_131» (Oracle Java). ОС с обоих сторон Debian 8.
В дополнение полезные картинки как работает аутентификация по сертификатам.
И полезная картинка применительно к самому мониторингу Java. 
Взял эту картинку их статьи «Узнать размер Java Heap Memory Size» — https://linux-notes.org/uznat-razmer-java-heap-memory-size/
И ещё пара выписок про память Java, так на заметку.
Heap Memory
Heap memory is the run time data area from which the memory for all java class instances and arrays is allocated. The heap is created when the Java Virtual Machine starts up and may increase or decrease in size while the application runs. The size of the heap can be specified using –Xms VM option. The heap can be of fixed size or variable size depending on the garbage collection strategy. Maximum heap size can be set using –Xmx option. By default, the maximum heap size is set to 64 MB.
Non-Heap Memory
The Java Virtual Machine has memory other than the heap, referred to as Non-Heap Memory. It is created at the JVM startup and stores per-class structures such as runtime constant pool, field and method data, and the code for methods and constructors, as well as interned Strings. The default maximum size of non-heap memory is 64 MB. This can be changed using –XX:MaxPermSize VM option.