Мониторинг Java. JMX мониторинг в Zabbix с использованием SSL

В этой статье я рассмотрю мониторинг работы java-приложения в системе мониторинга Zabbix.

В официальной документации Zabbix это называется JMX мониторинг.

Управленческие расширения Java (англ.  Java Management ExtensionsJMX) — технология 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.


В дополнение полезные картинки как работает аутентификация по сертификатам.

1way-vs-2way-ssl-new

И полезная картинка применительно к самому мониторингу Java. Java Heap Memory SizeВзял эту картинку их статьи «Узнать размер 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.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *