STALKER`s project::Blog

Несмотря на все многообразие модулей и способов настройки Nagios, все же свобода администратора этим не ограничивается. Далее приведен довольно свободный перевод из документации к Nagios по механизму обработчиков событий (event handlers).

Основной материал: http://nagios.sourceforge.net/docs/2_0/eventhandlers.html

Вступление

Обработчики событий это произвольные команды которые выполняются когда происходит изменения состояния сервиса или хоста. Преимуществом использования механизма event handlers (особенно с сервисами) может служить возможность для Nagios предварительно устранять проблемы до того как кто-либо будет оповещен о проблеме. Другой потенциальной сферой использования этого механизма это логирование событий происходящих с сервисами или хостами во внешнюю базу данных или лог.

Типы Event Handlers

Можно выделить 2 основных типа event handlers – для сервисов и для хостов. Объявлять обработчики событий можно для любого сервиса или хоста. Т.к. эти обработчики событий ассоциируются только с единственным хостом или сервисом я буду называть эти обработчики «локальными». Если локальный обработчик был объявлен для сервиса или хоста, он будет запущен когда состояние сервиса или хоста измениться.

Вы также можете объявить глобальный обработчик событий, который будет запускаться для каждого сервиса или хоста, когда его состояние меняется, используя опции nagios.cfg, global_host_event_handler или global_service_event_handler. Глобальный event handler запускается перед выполнением локального обработчика событий для сервиса или хоста.

Когда запускаются обработчики событий?

Обработчики событий для хостов и сервисов выполняется в случаях:

• перехода сервиса в «soft» состояние
• переход в «hard» состояние
• рекавери (возврат) из «soft» или «hard» состояния

Пер.: проще говоря во всех случаям смены сервисом состояния(WARN, CRIT, OK, UNKNOWN).
Описание что такое «soft» и «hard» состояние ошибки(проверки)вы можете найти здесь .

Порядок выполнения обработчиков

Глобальные обработчики событий всегда выполняются перед объявленными вами локальными обработчиками событий.

Написание обработчиков событий

В принципе обработчиками событий могут быть Shell или Perl скрипты. Как минимум, скрипт должен получать следующие макросы в качестве аргументов:

Обработчики сервисов: $SERVICESTATE$, $SERVICESTATETYPE$, $SERVICEATTEMPT$
Обработчики сервисов: $HOSTSTATE$, $HOSTSTATETYPE$, $HOSTATTEMPT$

Скрипт должен проанализировать эти аргументы и на основе полученных данных выполнить необходимые действия. Лучший способ понять как работают обработчики событий это посмотреть пример (он приведен ниже). К тому же существуют «стандартные» примеры обработчиков событий, они находятся в папке eventhandlers/ вашей инсталяции Nagios. Некоторые из них используют механизм external commands (переведено) для развернутого мониторинга хостов.

Permissions For Event Handler Commands

пропущен…

Debugging Event Handler Commands

пропущен…

Пример обработчика событий для сервиса

Следующий пример предпологает что вы проверяете HTTP сервер на локальном компьютере, и объявили обработчик событий restart-httpd для сервиса HTTP. Также предпологается что параметр установлен равным 4 или выше (т.е. сервис проверится 4 раза до того как его состояние можно считать проблемой). Пример объявления обработчика событий в сервисе:

define service{
host_name   somehost
service_description  HTTP
max_check_attempts  4
event_handler   restart-httpd
...другие папраметры сервиса...
}

Раз уж мы объявили обработчик в описании сервиса, мы должны объявить его как команду Nagios. Помните что макросы в командной строке объявленные здесь необходимы!

command{
command_name restart-httpd
command_line /usr/local/nagios/libexec/eventhandlers/restart-httpd  $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
}

Теперь напишем сам скрипт (он должен находиться в файле /usr/local/nagios/libexec/eventhandlers/restart-httpd).

#!/bin/sh
#
# Обработчик событий для перезагрузки локального HTTP сервера (Apache) в случае возникновения проблем
#
# Замечание: Этот скрипт будет перезагружать веб сервер только когда
#            сервис 3 раза не пройдет проверку (он еще будет в "soft" состоянии) или если снрвис как-то
#            перейдет в состояние "hard".
#
 
# В каком состоянии Nagios-сервис HTTP?
case "$1" in
OK)
# Сервису стало "хорошо"
;;
WARNING)
# Предупреждения на не важны, видимо пока все работает
;;
UNKNOWN)
# Мы не занем что случилось, поэтому ничего не делаем
;;
CRITICAL)
# Ага! С web-сервером похоже что-то случилось, пробуем перезапустить.
 
# Сервис в "soft" или "hard" состоянии?
case "$2" in
 
# Сервис в "soft" состоянии, т.е. о проблемме еще не было нотификаций...
SOFT)
 
# Проверяем сколько раз мы уже проверили сервис. Мы нехотим перезагружать сервис после первого непройденного теста
# т.к. это может быть просто "глюком".
case "$3" in
 
# Дожидаемся пока сервис провериться 3 раза.
# Если сервис не пройдет проверку и в 4й раз (после перезапуска) он перейдет в
# "hard" состоянии и администраторы будут оповещены о проблеме.
          # Будем надееться перезапуск поможет и мы сможем автоматически обработать проблему.
3)
echo -n "Restarting HTTP service (3rd soft critical state)..."
# вызаваем скрипт для перезапуска Apache
/etc/rc.d/init.d/httpd restart
;;
esac
;;
 
# HTTP сервис как-то перешел в "hard" состояние и наши действия ему не помогли.
# Давайте попробуем еще раз на всякий случай...
# Замечание: к данному времени все кому нужно уже были оповещены о проблеме
HARD)
echo -n "Restarting HTTP service..."
          # вызаваем скрипт для перезапуска Apache
/etc/rc.d/init.d/httpd restart
;;
esac
;;
esac
exit 0

…конец…

От себя добавлю что в случае с приведенным примером выполнение перезапуска Apache до того как были высланы нотификации не самая лучшая идея. Вы можете оказаться в ситуации когда проблемы была, но вы о ней не узнали, для проверки Apache стоит ставить малый normal_check_interval и не выполнять рестарт в «soft» состоянии (до посылки нотификации). Тогда вы узнаете о наличии проблемы и если рестарт поможет вы так-же быстро получите recovery, будете знать о проблеме и времени ее появления, что упростит анализ логов Apache.