Мониторинг приложений Grails, часть 2 — сбор данных

Поздравляем, вы запустили свой новый сайт Grails — теперь вам просто нужно убедиться, что он продолжает работать!

Мы уже видели, как предоставлять пользовательские данные для приложения Grails через JMX — но в этом посте мы сосредоточимся на элементах данных, которые мы могли бы собирать и отслеживать.

Если мы сделаем шаг назад, чего мы пытаемся достичь с помощью мониторинга нашего приложения?

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

Мой сайт работает?

Для некоторых людей это может быть « мой сайт приносит мне деньги? «Но они, вероятно, не будут зарабатывать деньги, если сайт не работает — так что давайте перейдем к доступности.

Это реактивный вопрос — если ответ «нет», выньте администратора системы из постели в 3 часа утра и восстановите службу!

Тем не менее, это критически важно, поэтому у вас обычно есть проверка HTTP, чтобы попасть на первую страницу сайта — HTTP-ответ будет проверяться для кода 2xx, и часто вы можете проверить ожидаемую строку в теле.

Для практической части этого поста мы будем использовать Opsview для демонстрации теории. Предполагая, что у вас установлено устройство Opsview VMWare и вы выполнили Quick Start , эта проверка для стандартного приложения Grails под названием «Monitored» может быть:

check_http -H $HOSTADDRESS$ -p 8443 --ssl -w 5 -c 10 -u '/monitored/js/application.js' -s 'spinner'

Порт TCP указывается с помощью -p, а флаг — ssl указывает проверке выполнить рукопожатие SSL.
В -w и -c опции пороговые значения предупреждения и критические соответственно время отклика в секундах.
Часть пути к контексту URL указывается параметром -u, а -s используется для проверки ожидаемой строки в содержимом.
Примечание : Opsview может показать справку плагина, которая перечислит другие опции и предоставит больше информации об использовании.

Если вы передаете свой сервер приложений веб-серверу, то обычно используется две проверки: одна для проверки через веб-сервер и другая для проверки непосредственно на сервере приложений. Это помогает точно определить, где проблема в случае сбоя. Если у вас есть серверы с балансировкой нагрузки — тогда проверки должны применяться ко всем узлам.

Как и во всем, эффективность этих проверок «входной двери» зависит от точки зрения сервера мониторинга. Если веб-страницы обслуживаются из того же центра обработки данных, что и сервер мониторинга, вы можете выбрать проверку исходящего соединения с известным сайтом или использовать 2-ю точку обзора, чтобы определить, изолирован ли ваш центр обработки данных от Интернета.

Например, это можно сделать, ПОЛУЧИв http://www.downforeveryoneorjustme.com/ нужный URL-адрес и проверив строку ответа «Это только вы»…

Второй большой вопрос обычно звучит так: « Что испытывают наши клиенты? ”- сфера мониторинга пользовательского опыта / искусственных транзакций выходит за рамки этого поста, однако вас может заинтересовать этот пост в блоге об использовании Opsview с Selenium .

Оперативная перспектива

Спускаясь по уровню с операционной точки зрения, вы захотите убедиться, что:

1. сервер включен
Это делается с помощью команды проверки хоста (например, ping / SSH)

2. сервер отвечает на соединения по соответствующим портам (включая 8080/8443).
Здесь мы используем check_tcp .

3. сервер приложений может подключаться к базе данных.
Это check_tcp, но выполняется агентом на сервере приложений и вызывается check_nrpe или check_by_ssh .

4. сервер базы данных отвечает на запросы.
Вы можете использовать check_sql_advanced , другие плагины Nagios check_sql или пользовательскую проверку (например, https://gist.github.com/994973 ).

5. почтовый сервер работает
Вы догадались, check_smtp .

Более активные проверки

Поскольку речь идет о приложениях Grails, мы сосредоточимся на Tomcat и JVM и предположим, что вы используете MySQL и запускаете его на сервере Linux с установленным пакетом агента Opsview (Opsview также может отслеживать серверы Windows с NSClient ++) и доступны через NRPE. (Я настоятельно рекомендую использовать iptables для ограничения доступа к порту NRPE только для сервера мониторинга).

Лучшие 5 вещей, которые нужно проверить на уровне ОС с примерами:

1. Загрузка ЦП / средняя нагрузка на сервер

check_load -w 8,5,2, -c 20,9,4

2. Количество свободной памяти

check_memory -w 90 -c 98

3. Объем свободного дискового пространства

check_disk -w 5% -c 2% -p /

4. Что запущен процесс Tomcat

check_procs -C jsvc -a tomcat -w 3:3 -c 3:3

5. Что процесс MySQL работает

check_procs -a mysqld --metric=CPU -w 60 -c 90

Мы проигнорируем файлы журнала сканирования для этого поста и предположим, что вы используете jAlarms для уведомления Opsview о любых проблемах, обнаруженных приложением ( инструкции здесь ).

JMX Проверяет

Это запрашивается check_jmx . Существует несколько вариантов, в том числе JNRPE, который имеет преимущество в том, что не запускает JVM для каждой проверки, однако для простоты мы предполагаем использование стандартной проверки jmxquery.jar .

1. Куча места (например, для -Xmx512m)

check_jmx -U service:jmx:rmi:///jndi/rmi://localhost:1616/jmxrmi -O
 java.lang:type=Memory -A HeapMemoryUsage -K used -I HeapMemoryUsage -J used -vvvv -w 400000000 -c 500000000

2. Активные подключения к базе данных

check_jmx -U service:jmx:rmi:///jndi/rmi://localhost:1616/jmxrmi -O 
bean:name=dataSourceMBean -A NumActive -vvvv -w 16 -c 19

3. Любые ключевые метрики приложения, которые вы показали через JMX (при условии, что веб-аналитика обрабатывается отдельно). Стандартные реализации check_jmx ожидают, что они будут числовыми

Это будет выглядеть в Opsview следующим образом (наблюдатель заметит, что есть доступные графики — продолжайте читать, чтобы узнать как):

Искусство мониторинга

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

Частота проверок.
Опять же, это должно быть сбалансировано: если вы будете делать слишком частые проверки, вы возьмете дополнительную нагрузку на свою систему и будете использовать вычислительную мощность, которая может обслуживать клиентов; если вы делаете чек слишком редко, вы можете упустить возможность предотвратить аварию или, что еще хуже, не знать о сбое / нарушении SLA до тех пор, пока не зазвонит телефон … В конечном счете, выбор за вами — хотя Opsview по умолчанию использует 5-минутный период проверки ,

Уведомления
Очевидно, что мы хотим, чтобы наша операционная команда была уведомлена в случае возникновения проблемы. Opsview поддерживает несколько каналов, таких как электронная почта, RSS с SMS и интеграция службы поддержки в версии Enterprise. Дополнительная информация о методах уведомлений здесь .

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

# java_HeapMemoryUsage_used
# Service type: Java JMX Heapspace check using check_jmx
# output:JMX OK HeapMemoryUsage.used=454405600{committed=532742144:init=0:max=532742144:used=454405600}
/output:JMX.*HeapMemoryUsage.used=([0-9]+).committed=([0-9]+).init=([0-9]+).max=([0-9]+)/
and push @s, [ "Heap_Memory",
[ "usedMB", GAUGE, $1/(1024**2) ],
[ "committedMB", GAUGE, $2/(1024**2) ],
[ "initMB", GAUGE, $3/(1024**2) ],
[ "maxMB", GAUGE, $4/(1024**2) ] ];

# JMX Active DB connections
# output:JMX OK NumActive=3
/output:JMX.*NumActive=([0-9]+)/
and push @s, [ "NumActive",
[ "NumActive", GAUGE, $1 ] ];

perl -c map.local