Примечание. В этой статье описывается сценарий, основанный на JBoss Fuse, но он применим к любому контексту Java, способному запускать сервлет Java, например, JBoss EAP, WildFly, Tomcat и т. Д.
Одним из моих недавних действий на работе было предоставление руководства по мониторингу настройки JBoss Fuse ESB с помощью Nagios / OpsView . Несмотря на наличие более специализированных решений для конкретной проблемы (плагин Fuse для Red Hat JON ), Nagios по-прежнему является одним из наиболее распространенных инструментов мониторинга с открытым исходным кодом.
Вам не нужен эксперт в Nagios, чтобы понять эту статью, я определенно нет. Но если у вас есть и у вас есть предложения по улучшению этого решения, дайте мне знать, пожалуйста.
Nagios — это инструмент мониторинга с открытым исходным кодом, который с помощью плагинов может собирать множество метрик из различных видов сервисов и уведомлять вас, когда определено определенное значение или определенный шаблон (значения во времени). Его можно использовать для отслеживания состояния скрытой пользовательской развернутой прикладной программы более скрытых значений, при условии, что вы зададите, что важно для вас.
В нашем примере наше пользовательское приложение развернуто на JBoss Fuse ESB .
Большинство метрик, которые мы хотим отслеживать, связаны с Apache Camel , Apache ActiveMQ и Apache CXF. Эти проекты уже отлично справляются с задачей раскрытия множества интересующей нас информации во время выполнения. Например, Camel сообщает нам, сколько сообщений прошло через определенный компонент или каков статус некоторых наших маршрутов.
Технология, которую эти проекты используют для раскрытия столь большого количества ценной информации, — это JMX.
Nagios поддерживает JMX с помощью внешних плагинов.
Мы исследовали следующий список:
- check_jmx JMX-атрибуты через RMI.
- check_http с Джолокией
- check_jmx4perl с Джолокией
check_jmx
Мы нашли некоторые проблемы с этим подходом:
1) чтобы разрешить связь RMI, сетевой уровень должен разрешить соединение с определенными портами.
2) плагин поддерживает только атрибуты, а не операции
3) создание запросов JMX не особенно удобно для пользователя, особенно если вы не являетесь разработчиком / разработчиком Java
Поскольку у нас была необходимость вызывать какую-либо операцию как часть наших требований к мониторингу, мы были вынуждены искать другие альтернативы.
check_http с Джолокией
Одной из наших первых альтернативных идей было использование Jolokia.
Jolokia — это java-библиотека, которая предоставляет интерфейсы JMX через HTTP с API-интерфейсом REST на основе JSON .
Чтобы сделать свое волшебство над http, ему просто нужно вызвать точку входа http, то есть сервлет. Я оставляю вам официальную инструкцию Jolokia по его установке, но как только вы установите эти компоненты на место, вы готовы использовать его функции мостового соединения JMX.
Но я также поделюсь с вами небольшим трюком : я не установил Jolokia вручную. Поскольку мы уже используем awesome hawt.io в качестве консоли управления и поскольку она использует Jolokia, все, что нам было нужно, уже было там.
Давайте рассмотрим преимущества использования решения на основе jolokia.
Будучи основанным на http, он явно помогает с проблемами конфигурации сети:
Мне все еще трудно принять это, но по опыту многих клиентов обработка конфигурации корпоративной сети часто оказывается более сложной, чем ожидалось. Что-то, что кажется простым на абстрактной бумажной диаграмме, перестает быть таким, когда у вас нет подробностей о топологии сети, и единственное, что вы можете увидеть, это то, что сквозная связь не работает. По этой причине, в зависимости от популярного протокола http, безусловно, привлекательная функция.
Второе дополнительное преимущество заключается в том, что, в отличие от check_jmx, он поддерживает вызов операции JMX . Эта последняя функция оказывается полезной, если интересующие вас метрики представлены не как атрибуты, а только как операции. Одним из примеров является операция:
|
1
|
osgi.core:type=bundleState,version=1.5/getState |
Что касается эргономичности интерфейса, я лично считаю, что он предлагает очень прямолинейное чувство.
Запросы могут быть простыми. В итоге вы можете вызвать очень аккуратную конечную точку REST через GET, что-то похожее на это:
|
1
|
curl -u admin:admin http://172.17.42.1:8012/jolokia/read/java.lang:type=Memory/HeapMemoryUsage |
Но в тот момент, когда вы начинаете отправлять сложные входные данные или когда вы можете положиться на POST и внешние входные файлы, содержащие ваши json-данные. Я предлагаю вам проверить полезный пост Якуба Кораба: http://www.jakubkorab.net/2013/11/monitoring-activemq-via-http.html
Чтобы использовать Jolokia напрямую из Nagios, мы можем использовать общий плагин check_http, который имитирует поведение скручивания, как в предыдущем примере. Единственный недостаток в том, что check_http не предлагает поведения для обработки строк json, которые являются структурой, которую возвращает jolokia. Возможно, вы сможете проанализировать вывод с помощью регулярных выражений и простой проверки значений, но мы чувствуем, что что-то упустили. А то, чего здесь не хватает, вместо этого предлагается следующим вариантом.
check_jmx4perl с Джолокией
jmx4perl — это набор библиотек и скриптов Perl, которые позволяют взаимодействовать с объектами JMX, открытыми для jolokia. Одним из инструментов, связанных с проектом, является плагин Nagios: check_jmx4perl
Не пугайтесь ключевого слова «perl». Я не пишу на Perl, и у меня проблемы с его чтением. И все же я могу использовать инструмент. Проект предоставляет вам исполняемые скрипты, которые вы можете вызывать из командной строки для запроса сервисов JMX, предоставляемых Jolokia, а также предоставляет совместимый с Nagios исполняемый файл.
С помощью этого инструмента вы можете написать такие запросы:
|
01
02
03
04
05
06
07
08
09
10
11
|
$ check_jmx4perl \ --user=admin \ --password=admin \ --url http://10.21.21.1:8012/jolokia \ --name "[MyService - CamelContext - WebService]" \ --mbean "org.apache.camel:context=mycontext/86-MyRoute.Request,name=\"log\",type=components" \ --attribute "State" \ --critical Stopped \ --warning !StartedOK - MyService - CamelContext - WebService] : 'Started' as expected | 'MyService - CamelContext - WebService]'=Started;!Started;Stopped |
И, как вы можете догадаться, читая предыдущую команду, поддержка Nagios происходит очень быстро, позволяя вам указать значения, которые вы хотите идентифицировать как представляющие статус Предупреждение или Ошибка.
Если вы знакомы с Nagios, вы знаете, что для использования исполняемого файла вы должны определить его в конфигурации Nagios.
Это пример возможных макросов:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
### check_jmx4 supports wildcards! ( you can use asterisk everywhere in the string names )# Read JMX attributes without support for nested attributes define command { command_name check_jmx4perl_attribute_absolute command_line /usr/local/bin/check_jmx4perl \ $ARG1$ \ --url $ARG2$ \ --mbean $ARG3$ \ --attribute $ARG4$ \ $ARG5$ }# Check Bundle is Activedefine command { command_name check_jmx4perl_bundle_is_active command_line /usr/local/bin/check_jmx4perl \ $ARG1$ \ --url $ARG2$ \ --warning \!ACTIVE \ --critical \!ACTIVE \ --mbean "osgi.core:type=bundleState,version=1.5" \ --operation "getState(long)" \ $ARG3$ } |
После того как вы определили эти макросы в Nagios, вы можете определить ваши реальные вызовы мониторинга, которые используют эти команды. Что-то типа:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
# Root service definition that presets some values and variablesdefine service { use generic-service name jolokia register 0 host_name localhost _agenturl http://172.17.42.1:8012/jolokia _authentication --user=admin --password=admin }# Sample Bundle is Activedefine service { service_description Sample Bundle is Active use jolokia check_command check_jmx4perl_bundle_is_active\ !$_SERVICEAUTHENTICATION$ \ !$_SERVICEAGENTURL$ \ !74 } |
Как это проверить?
Несмотря на то, что установка и настройка Nagios — это не ракетостроение, это не всегда простое занятие . Иногда вы делаете глупые опечатки или просто оставляете место в неправильном месте, и ничего не работает. Несмотря на то, что у вас есть чувство, что вы можете исправить это всего за некоторое время, оно превращается во воровство, которое отвлекает вас от огромного списка других дел.
Или, может быть, вы такой же, как я: тот факт, что вам удалось все настроить за пару дней, не означает, что вы сможете точно вспомнить, как, если спросить через месяц.
По всем этим причинам я решил повеселиться с Docker .
Docker — это крутой и новый инструмент, который вы можете использовать для предоставления связанных стеков приложений , называемых контейнерами; они могут быть предварительно настроены именно так, как вы хотите. Я собрал контейнер Docker, который запускает для вас экземпляр Nagios и предоставляет все плагины, сценарии и пример конфигурации, которые я обсуждал в этом посте .
Если вы не заинтересованы в Docker, вы все равно можете найти образец в этом репозитории GitHub и в конечном итоге все равно прочитать файл Docker, который в конце дает все шаги, которые вам необходимы для установки и настройки Nagios с jmx4perl.
Поскольку мои знания основаны на информации, уже доступной в Интернете, это небольшой список ресурсов, которые помогли мне составить это руководство:
- http://www.jakubkorab.net/2013/11/monitoring-activemq-via-http.html
- http://search.cpan.org/~roland/jmx4perl-1.07/scripts/check_jmx4perl#Parameterized_checks
- http://labs.consol.de/lang/en/blog/jmx4perl/check_jmx4perl-einfache-servicedefinitionen/
