Мониторинг сложных распределенных систем может стать настоящей головной болью как с точки зрения первичной настройки метрик и поддержания их актуальности, так и с точки зрения производительности. Легче всего предотвратить большинство проблем заранее, ещё на стадии проектирования.

Наиболее распространенные проблемы:

  • Производительность – при обработке большого количества метрик со многих узлов система мониторинга может не справляться с обработкой входящего потока данных.
  • Влияние мониторинга на работу системы – сбор метрик может быть достаточно затратен для конечной системы.
  • Излишняя сложность – система мониторинга должна быть той частью, которой вы доверяете. Чем сложнее решение, тем выше вероятность отказа, особенно в случае каких-либо изменений.

Общие рекомендации при построении системы мониторинга:

  • Проще – лучше.
  • Уменьшайте нагрузку на сервер сбора метрик – при большом количестве узлов сложные вычисления лучше проводить на них и передавать серверу готовые значения.
  • Уменьшайте частоту сбора метрик – она должна быть минимально достаточной для выявления проблем, особенно это актуально для “тяжелых” метрик.
  • Автоматизируйте регулярно выполняемые действия – ручные действия при увеличении количества узлов неминуемо приведут к ошибкам.

Используя эти рекомендации, создадим шаблон и настроим мониторинг тестового кластера. Полученный в итоге шаблон доступен в репозитории zabbix.

Свой Майнкрафт Сервер! Как создать? | Майнкрафт Открытия

Создание шаблона

Для построения мониторинга вашей мечты необходимо хорошо понимать продукт, работу которого вы хотите отслеживать и оценивать.

Apache Ignite – это in-memory computing platform, платформа используемая как кэш, распределённая вычислительная система и база данных. Начать более подробное изучение продукта можно с официальной документации. Ключевые внешние показатели производительности системы – это практически стандартный набор:

  • Загрузка CPU
  • Утилизация RAM
  • Утилизация дисков в случае persistence
  • Сеть

Шаблоны для мониторинга данных метрик уже содержатся в zabbix, а для расширенных метрик наподобие утилизации диска есть готовые решения, доступные в репозитории zabbix, например, такое.

Снижение внешних показателей, до предельных значений, будет говорить о сбоях в аппаратной части, которые распределённые системы, как правило, переживают без последствий или о полной недоступности системы, когда сервис уже недоступен. Для того, чтобы обнаруживать опасные ситуации заранее, до момента возникновения инцидента, необходимо контролировать и внутренние показатели продукта. На момент написания статьи готовых шаблонов для Apache Ignite не было, поэтому напишем свой.

Так как Ignite написан на Java, основным способом мониторинга для него будет являться JMX. Если мы просто скачаем и запустим Ignite, jmx-порт будет открыт на первом свободном порту между 49112 и 65535. Для мониторинга нас такой подход не устраивает, так как, как правило, порт настраивается заранее и способов его автоматического определения по умолчанию нет. После ознакомления со скриптом запуска становится понятно, что для того, чтобы самому указать необходимый порт, можно использовать переменную окружения IGNITE_JMX_PORT. Таким образом, выполнив команду export IGNITE_JMX_PORT=49112 и запустив узел, мы получим доступ к JMX на известном нам статическом порту.

Странные сервера из бесплатного мониторинга Майнкрафт

Начиная с версии Ignite 2.10, jmx-порт задаётся по другому

Начиная с версии 2.10, это поведение изменено и в будущих версиях необходимо использовать переменную JVM_OPTS. Открыть jmx-порт можно следующим образом:

export JVM_OPTS=»-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=49112 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false»

Особенность, на которую стоит обратить внимание, – по умолчанию в пути к mbean присутствует classloader, который будет меняться после каждого перезапуска узла. Он добавлялся для возможности запуска нескольких инстансов Ignite в рамках одной JVM, чтобы избежать конфликта метрик, но сейчас это не наш случай. Для нас же это будет значить, что zabbix будет обнаруживать метики заново после каждого перезапуска. Решить эту проблему можно, добавив JMX-опцию -DIGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false, она уберёт classloader из пути.

mbean с classloader

Ignite находится в opensource, поэтому если вы уверены, что какая-то функциональность должна работать по-другому, то вы можете принять участие в разработке. В данном случае я так считаю и сразу завёл задачу в JIRA ASF.

В результате дерево метрик будет выглядеть следующим образом:

Интерфейс jconsole

Чтобы облегчить процесс добавления новых метрик себе и упростить процесс их изменения в дальнейшем, в первую очередь определим, какие объекты имеют схожую сущность. В Java для этого, как правило, используется реализация интерфейса. В нашем случае, изучая, например, метрики в разделе Thread pool, можно увидеть, что все объекты реализуют интерфейс ThreadPoolMXBean.

Описание объекта

В рамках решаемой задачи нас интересует тот факт, что каждый из этих объектов будет иметь один базовый набор метрик. Применительно к шаблонам zabbix это означает, что мы можем настроить discovery rule для этих метрик, после чего сервер мониторинга будет обнаруживать все идентичные объекты на основе нашего правила и применять к ним шаблон.

Читайте также:  Как опьянеть в Майнкрафт

Например, правило для обнаружения всех dataRegion будет выглядеть следующим образом:

Создание правила обнаружения

В качестве значения : zabbix будет подставлять адрес, по которому доступен узел, с применённым шаблоном и указанное в качестве jmx-порта значение.

Дебаг jmx discovery

Если возникнет необходимость отдебажить обнаружение в JMX, это можно сделать с помощью команды zabbix_get. Пример discovery-запроса списка дата-регионов:

zabbix_get -s localhost -p 10052 -k »

Результат будет выглядеть следующем образом следующий результат:

< «»:»org.apache», «»:»org.apache:group=DataRegionMetrics,name=sysMemPlc», «»:»sysMemPlc», «»:»DataRegionMetrics» >,< «»:»org.apache», «»:»org.apache:group=DataRegionMetrics,name=default», «»:»default», «»:»DataRegionMetrics» >,< «»:»org.apache», «»:»org.apache:group=DataRegionMetrics,name=TxLog», «»:»TxLog», «»:»DataRegionMetrics» >

Пример шаблона метрики:

Создание метрики на основе правила обнаружения

Параметры и аналогичные zabbix берёт из результата discovery-запроса.

В итоге я выделил несколько групп метрик, для которых стоит использовать механизм discovery:

  • Дата-регионы
  • Кэш-группы
  • Кэши
  • Пулы потоков

Остальные метрики, такие как текущий координатор, количество клиентских и серверных узлов, количество транзакций на узле и тому подобное, добавляем в отдельную группу.

Развертывание и автоматизация

Имея все необходимые шаблоны и понимание работы продукта, настроим мониторинг тестового стенда. Для изоляции процессов я буду использовать docker.

Как это всё будет работать:

  1. Zabbix server регистрирует новый узел после получения первого запроса от zabbix agent.
  2. Zabbix server выполняет скрипт, который добавляет jmx-порт и применяет шаблоны к новому узлу.
  3. Zabbix server начинает посылать запросы на Java gateway, который, в свою очередь, опрашивает приложение и возвращает метрики.
  4. Zabbix agent получает от сервера список собираемых активных метрик и начинает их отправлять на zabbix server.
  5. Zabbix server запрашивает значения пассивно собираемых метрик у zabbix agent.

Метрики от приложения поступают по JMX, новые узлы регистрируются после первого обращения zabbix agent к серверу.

Подробнее о том почему в п.2 используется самописный скрипт

  • Изначально было желание использовать функционал zabbix, но zabbix “из коробки” не умеет присваивать jmx port новым узлам, а без этого нельзя привязать шаблон, использующий JMX. Предложение по доработке есть в jira zabbix с 2012 года, но оно до сих пор в open.
  • Реализация данного функционала через API возможна, но потребует создания служебного пользователя и будет более тяжелой в случае необходимости регистрации большого количества узлов.
  • Вариант через базу данных, описанный в тикете, возможно, применим для postgresql, но не работает на Oracle, MySQL и MariDB, так как в этих БД нельзя настроить триггер, который будет делать вставку в ту же таблицу, на которой он сработал.
  • Вариант с добавлением в рамках скрипта только интерфейса также не увенчался успехом, так как Zabbix не позволяет управлять порядком выполняемых операций в действии. Они выполняются в порядке создания, но внешние скрипты и отправка оповещения помещаются в отдельную очередь, обрабатываемую после выполнения всех остальных операций.

Схема тестового окружения

  1. Скачиваем и устанавливаем docker и docker-compose, если они ещё не установлены.
  2. Скачиваем все необходимые файлы из репозитория.
  3. Переходим в скачанную папку.
  4. Запускаем сборку образа: docker-compose -f docker-compose-zabbix.yml build
  5. Запускаем кластер и сервер мониторинга: docker-compose -f docker-compose-zabbix.yml up
  6. Через несколько секунд zabbix будет доступен на 80 порту. Учётная запись по умолчанию – Admin / zabbix .

Как импортировать шаблоны:

  1. Идём на вкладку Configuration->Templates->Import и импортируем шаблон ignite_jmx.xml (находится в папке, скачанной ранее). Вместе с самим шаблоном будет добавлена группа ‘Templates/Ignite autoregistration’, это название будет использоваться далее для добавления шаблонов из этой группы к новым узлам.
  2. В каждом шаблоне, который должен быть применён, указываем созданную на предыдущем шаге группу. Шаблон Template App Ignite JMX в ней уже содержится, я добавил Template App Generic Java JMX и Template OS Linux by Zabbix agent.

Создаём скрипт для авторегистрации агентов:

Добавление запуска скрипта в правило авторегистрации

  1. В интерфейсе zabbix переходим на вкладку Configuration->Actions, в выпадающем списке выбираем Autoregistration actions и создаём новое действие.
  2. Даем название действию. Можем настроить условия добавления узла.
  3. В операциях добавляем пункт Add host. Это создаст новый узел в zabbix в случае выполнения условий, указанных ранее.
  4. Добавляем запуск скрипта autoreg.php, который будет добавлять jmx-порт в настройки и применять шаблоны из указанной группы к переданному узлу. Для тех, кто разворачивает тестовый кластер из образа, он будет находиться в папке /var/lib/zabbix, для тех, кто устанавливает самостоятельно, – в репозитории, указанном выше. Запускаться в моём случае он будет командой php /var/lib/zabbix/autoreg.php ‘Templates/Ignite autoregistration’ » . Должно получиться так:
Читайте также:  Как сделать зелье огнестойкости в майнкрафте

Если всё было сделано корректно, узлы должны появиться в zabbix с настроенным jmx-портом и применёнными шаблонами из группы. Если что-то пошло не так, первое, что рекомендую проверить, – Reports->Audit log.

Результаты и куда двигаться дальше

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

После настройки мониторинга для вашего решения неизбежно будет появляться необходимость его дорабатывать. В случае, если текущая конфигурация не смогла предотвратить аварийную ситуацию, – необходимо добавлять новые метрики. Также иногда будет полезно убирать из мониторинга не используемые вами метрики, это позволит разгрузить как систему мониторинга, так и приложения, и железо.

Помимо Apache Ignite в вашем решении, вероятно, будет присутствовать ещё немало компонентов, таких как клиентские приложения, фронтенды, очереди, сетевое оборудование, СХД и тому подобное, – всё это также требует мониторинга, без которого часть аварийных ситуаций не будет вовремя обнаружена.

Для многих будут актуальны вопросы безопасности. JMX и zabbix поддерживают как передачу метрик, так и работу интерфейса с использованием SSL-соединения. Но это уже отдельная большая тема.

Что почитать

  1. Site Reliability Engineering
  2. Zabbix documentation portal
  3. Готовый инструмент для мониторинга и управления Ignite и Gridgain

Источник: temofeev.ru

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

В этой статье я рассмотрю мониторинг работы 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 color: #0000ff;»>-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 Heap Memory Size

И полезная картинка применительно к самому мониторингу 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.

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

Для отправки комментария вам необходимо авторизоваться.

Источник: unix-garage.tk

Мониторинг в реальном времени с использованием интерфейса JMX

В этой статье описывается, как выставлять JMX MBeans в JIRA для мониторинга с помощью JMX-клиента.

Это руководство представляет собой базовое введение в интерфейс JMX и предоставляется как есть. Наша группа поддержки может помочь вам устранить неполадку по конкретной проблеме JIRA, но не может помочь вам настроить вашу систему мониторинга или интерпретировать результаты.

Что такое JMX?

JMX (Java Management Extensions) — это технология мониторинга и управления приложениями Java. JMX использует объекты, называемые MBeans (Managed Beans), чтобы выставлять данные и ресурсы из вашего приложения. Для больших экземпляров JIRA Server или JIRA Data Center включение JMX позволяет вам более легко контролировать потребление ресурсов приложений. Это позволяет вам принимать более эффективные решения о том, как поддерживать и оптимизировать ресурсы машины.

Метрики, собранные JIRA

В следующей таблице перечислены показатели (MBeans), которые собираются JIRA. Все они сгруппированы в собственность com.atlassian.jira.

Сброс после перезапуска JIRA

Количество просмотров всех панелей управления пользователями.

Источник: jiraved.ru