вторник, 13 июля 2010 г.

Непостоянные сервисы (Volatile services)


Введение
Система мониторинга Icinga способна различать "нормальные" и "непостоянные" сервисы. Опция is_volatile задается в определении сервиса и определяет, будет ли является сервис непостоянным или нет. В большинстве случаев многие будут использовать "нормальные" сервисы, однако, при правильном использовании, непостоянные сервисы могут оказаться крайне полезными.


Где могут быть полезны непостоянные сервисы?
Непостоянные сервисы могут быть полезны в следующих случаях:
·      Для мониторинга сервисов, которые автоматически сбрасываются в состояние "OK" после каждой проверки;
·      Для мониторинга событий, которые требуют рассмотрения (внимания) каждый раз при возникновении проблемы (а не только первый раз после ее возникновения), например, предупреждения о нарушении безопасности.

Особенности непостоянных сервисов
Непостоянные сервисы имеют три основных отличия от "нормальных" сервисов. Они проверяются всякий раз, когда находятся в проблемном состоянии типа HARD , а также когда результатом проверки является отличное от "OK" состояние (то есть не происходит восстановление состояния в положительное состояние "OK"), при этом:
·      в журнале сообщений регистрируется проверка, которая находится в состоянии отличном от состояния "OK"
·      о проблеме оповещаются контактные лица (если это настроено ).
            Замечание
            Для непостоянных сервисов игнорируются интервалы уведомления.
·      для сервиса выполняется обработчик событий (если он был определен).

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

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

Сила двух
Можно реализовать очень полезные вещи, если совместить использование функций непостоянных сервисов и пассивных проверок сервиса . Например, обработку SNMP-трапов, предупреждения о нарушении безопасности, и т.д.
Рассмотрим следующий пример:
Предположим, Вы используете PortSentry для обнаружения сканирования портов Вашей машины и автоматической блокировки потенциального злоумышленника с помощью средств межсетевого экранирования. Если Вы хотите сообщить системе мониторинга Icinga о сканировании портов, сделайте следующее:
Конфигурация системы мониторинга Icinga:
·      Определите сервис (define service {...}) с именем Port Scans и свяжите его с хостом, на котором работает PortSentry.
·      Установите значение параметра max_check_attempts сервиса равным 1. Это позволит системе мониторинга Icinga незамедлительно переводить сервис в состояние типа HARD в случае, если сервис окажется в состоянии отличном от "OK".
·      Установите значение параметра active_checks_enabled сервиса равным 0. Это запретит системе мониторинга Icinga выполнять активные проверки для данного сервиса.
·      Установите параметр passive_checks_enabled сервиса равным 1. Это включит пассивные проверки сервиса.
·      Установите параметр is_volatile сервиса равным 1.
Конфигурация PortSentry:
Отредактируйте конфигурационный файл PortSentry (portsentry.conf) и определите команду KILL_RUN_CMD следующим образом:
KILL_RUN_CMD="/usr/local/Icinga/libexec/eventhandlers/submit_check_result host_name 'Port Scans' 2 'Port scan from host $TARGET$ on port $PORT$.  Host has been firewalled.'"
Убедитесь в том, что Вы заменили host_name (в определении команды KILL_RUN_CMD) кратким названием хоста, с которым связан определенный в системе мониторинга Icinga сервис.
Сценарий Сканирования портов:
Создайте shell-скрипт в каталоге /usr/local/icinga/libexec/eventhandlers со следующим именем - submit_check_result. Содержание shell-скрипта должно быть следующим:
#!/bin/sh

# Write a command to the Icinga command file to cause
# it to process a service check result

echocmd="/bin/echo"

CommandFile="/usr/local/icinga/var/rw/nagios.cmd"

# get the current date/time in seconds since UNIX epoch
datetime=`date +%s`

# create the command line to add to the command file
cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$3;$4"

# append the command to the end of the command file
`$echocmd $cmdline >> $CommandFile`

Что произойдет, когда PortSentry обнаружит сканирование портов на хосте?
·      PortSentry заблокирует хост потенциального злоумышленника (это стандартная возможность программного обеспечения PortSentry),
·      PortSentry выполнит shell-скрипт submit_check_result и тем самым отправит результат пассивной проверки системе мониторинга Icinga
·      система мониторинга Icinga обработает файл внешних команд и увидит представленную  PortSentry пассивную проверку сервиса
·              система мониторинга Icinga переведет сервис Port Scans  в состояние CRITICAL типа HARD и отправит уведомления контактным лицам.

Читать далее...

воскресенье, 11 июля 2010 г.

Внешние Команды (External Commands)


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




Включение Внешних команд
Для того чтобы система мониторинга Icinga обрабатывала внешние команды, необходимо обеспечить выполнение следующих условий:
·      Включите проверку поступления внешних команд с помощью опции  check_external_commands .
·      Путем изменения опции command_check_interval установите частоту проверок.
·      Определите расположение командного файла с помощью опции command_file .
·      Установите правильные права доступа к каталогу, содержащему файл внешних команд (подробнее об этом, описано в руководстве по быстрому запуску ).

Когда Icinga выполняет проверку поступления внешних команд?
·      Icinga выполняет проверку поступления внешних команд регулярно, в соответствии с интервалом, определенным опцией command_check_interval   в основном конфигурационном файле
·      Сразу же после выполнения обработчиков событий . Эта дополнительная мера необходима для того, чтобы обеспечить незамедлительное выполнение внешних команд, которые могут поступить от обработчика событий.

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

Формат внешних команд
Внешние команды, записываемые в файл команд , имеют следующий формат:

[time] command_id; command_arguments
где time - время (в формате time_t) записи внешним приложением команды в файл команд . Значения command_id и command_arguments будут зависеть от того, какая команда передается демону Icinga.
Полный листинг внешних команд, которые могут использоваться в Icinga и Nagios (а также примеры их использования) можно найти по следующей ссылке:

Читать далее...

пятница, 9 июля 2010 г.

Обработчики событий (Event handlers)


Введение
Обработчики событий - это дополнительные системные команды (скрипты или исполняемые файлы), которые выполняются каждый раз при изменении состояния проверки хоста (host) или сервиса (service).
Основное предназначение обработчиков событий заключается в предоставлении возможности автоматически исправлять ошибки, прежде кто-либо из контактных лиц будет оповещен о проблеме. Ниже приведены другие варианты использования обработчиков событий:
·      Перезапуск отказавшего (проблемного) сервиса
·      Регистрация заявки на устранение неисправности в системе helpdesk
·      Журналирование информации о событии (например, сохранение в базе данных)
·      Периодическая автоматическая перезагрузка хоста*
·      и т.д.

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

Когда выполняются обработчики событий?
Обработчики событий выполняются, когда сервис или хост:
·      находится в проблемном состоянии типа SOFT
·      впервые перешел в проблемное состояние типа HARD
·      восстановился после проблемного состояния типа SOFT или HARD
Состояния проверок типа SOFT и HARD подробно описываются здесь.


Типы обработчиков событий
В Icinga/Nagios выделяются несколько типов обработчиков событий, с помощью которых можно организовать обработку изменений состояния хоста или сервиса:
·      Глобальный обработчик событий хоста (Global host event handler)
·      Глобальный обработчик событий сервиса (Global service event handler)
·      Локальные обработчики событий хоста (Host-specific event handlers)
·      Локальные обработчики событий сервиса (Service-specific event handlers)
Глобальные обработчики событий хоста и сервиса выполняются при изменении состояния любого хоста или сервиса, соответственно. Глобальные обработчики событий выполняются до обработки локальных и задаются с помощью опций  global_host_event_handler и global_service_event_handler в основном конфигурационном файле.
Локальные хосты и сервисы могут иметь свой собственный обработчик событий, который будет выполняться при изменении состояния проверки. Задать данный обработчик можно с помощью директивы event_handler в графе описания (определения) хоста или сервиса (define host и define service ). Локальные обработчики выполняются сразу же после Глобальных (если они заданы).

Включение обработчиков событий
Обработчики событий могут быть включены или выключены глобально для всей программы с помощью директивы enable_event_handlers в основном конфигурационном файле.
Локальные обработчики событий могут быть включены или выключены с помощью опции event_handler_enabled в области определения хоста или сервиса . Если выключена глобальная переменная enable_event_handlers   локальные обработчики событий так же не будут выполняться.

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

Написание команд обработчика событий
Командами обработчика событий могут быть любые файлы, которые можно выполнить в командной строке (например, это могут быть perl-скрипты или скрипты командной оболочки). Как минимум, скрипты должны принимать на входе качестве аргументов следующие макросы:
Для Сервисов: $SERVICESTATE$ , $SERVICESTATETYPE$ , $SERVICEATTEMPT$
Для Хостов: $HOSTSTATE$ , $HOSTSTATETYPE$ , $HOSTATTEMPT$
Скрипты должны обрабатывать данные аргументы и, основываясь на полученных значениях, предпринимать необходимые действия. Для лучшего понимания разберите пример приведенный ниже .

Подсказка
Дополнительные демонстрационные сценарии обработчиков событий могут быть найдены в подкаталоге contrib/eventhandlers/ дистрибутива Icinga. Некоторые из этих сценариев демонстрируют использование внешних команд , чтобы реализовать отказоустойчивость и распределенную среду мониторинга.

Полномочия команд обработчика событий
Команды обработчика событий обычно выполняться с полномочиями процесса Icinga. В некоторых случаях это может оказаться неудобным, например, если вы хотите написать обработчик событий, который выполняет  перезапуск сервиса (данная процедура требует наличия полномочий пользователя root).
В идеале, необходимо определить обработчики событий, которые вы хотите внедрить, и предоставить пользователю Icinga полномочия для выполнения необходимых системных команд. Либо, вместо этого, вы можете использовать утилиту sudo .

Пример обработчика событий сервиса
Данный пример предполагает, что Вы осуществляете мониторинг сервера HTTP на локальной машине и определили restart-httpd как команду локального обработчика событий сервиса HTTP. Также предполагается, что Вы установили значение опции max_check_attempts контролируемого сервиса 4 или более (то есть сервис будет проверяется 4 раза после возникновения проблемы, прежде чем статус проверки перейдет в состояние типа HARD). Ниже представлен пример определения сервиса с обработчиком событий:
 define service {
        host_name somehost
        service_description HTTP
        max_check_attempts 4
        event_handler restart-httpd
        ...
        }
После определения сервиса необходимо определить команду обработчика событий restart-httpd как показано ниже. Обратите особое внимание на макросы, которые передаются в командной строке (command_line), они важны!
define command {
        command_name restart-httpd
        command_line /usr/local/icinga/libexec/eventhandlers/restart-httpd $SERVICEATTEMPT$ $SERVICESTATETYPE$ $SERVICESTATE$
        }
Теперь, давайте напишем скрипт обработчика событий  /usr/local/icinga/libexec/eventhandlers/restart-httpd.
#!/bin/sh
#
# скрипт обработчика событий перезапускающий веб-сервер на локальной машине
#
# Примечание: Этот скрипт перезапустит веб-сервер в случае, если сервис
# будет в проблемном состоянии типа SOFT 3 раза подряд (таким образом, скрипт пытается перезапустить сервис до того, как будет выполнено оповещение) или, если веб-сервер, так или иначе,
# умудриться перейти в проблемное состояние типа HARD (при переходе в данное состояние сработает оповещение).
#


#, В каком состоянии находится сервис HTTP?
case "1$" in
OK)
        # сервис только что восстановился, так что ничего не делайте...
        ;;
WARNING)
        # Мы не обрабатываем состояние warning поскольку сервис, возможно все еще запущен...
        ;;
UNKNOWN)
        # Не известно, что могло бы вызывать ошибку, так что лучше ничего не делать...
        ;;
CRITICAL)
        # Ага! У сервиса HTTP, кажется, есть проблема - возможно, необходимо перезапустить его...

        # это состояние типа SOFT или HARD?
        case "2$" in
               
        # Мы находимся в проблемном состоянии типа SOFT, это означает, что Icinga находится на полпути к тому, чтобы перейти в состояние типа HARD и произвести оповещение контактов...
        SOFT)
                       
                # Сколько проверок было произведено ранее? Мы не хотим перезапускать веб-сервер при возникновении состояния типа SOFT впервые, поскольку это может быть просто ложное срабатывание или какая либо случайность!
                case "3$" in
                               
                # Ожидаем, пока количество не успешных проверок не будет равно 3 прежде, чем перезапустить веб-сервер.
                # Если 4 раза проверка выполнилась неуспешно (даже, несмотря на перезагрузку сервиса при 3-й проверке), то состояние проверки измениться на HARD и будет выполнено оповещение контактов.
                # Мы надеемся, что перезапуск веб-сервера произойдет успешно, сервис восстановится. При этом 4-ая проверка переведет сервис в нормальное состояние типа SOFT. Если это произойдет, уведомление не будет оправлено, поскольку проблема будет решена.
                3)
                        echo -n "Restarting HTTP service (3rd soft critical state)..."
                        # Вызов init сценария, чтобы перезапустить сервер HTTPD
                        /etc/rc.d/init.d/httpd restart
                        ;;
                        esac
                ;;
                               
        # сервис HTTP, каким-то образом попал в проблемное состояние типа HARD и проблема не была решена.
        # По идее, сервис должен был быть перезапущен выше по коду, но по каким-то причинам этого не произошло. Так давайте же дадим ему еще одну попытку? 
        # Примечание: Контактные лица, указанные при определении сервиса, уже были оповещены о проблеме (если Вы не отключили уведомления для этого сервиса)
        HARD)
                echo -n "Restarting HTTP service..."
                # Вызов init сценария, чтобы перезапустить сервер HTTPD
                /etc/rc.d/init.d/httpd restart
                ;;
        esac
        ;;
esac
exit 0

Данный демонстрационный скрипт, будет пытаться перезапустить веб-сервер на локальной машине в следующих случаях:
·      После того, как сервис был перепроверен в 3-ий раз и находится в состоянии CRITICAL типа SOFT
·      После того, как сервис перейдет в состояние CRITICAL типа HARD
Приведенный скрипт должен теоретически перезапустить и веб-сервер и решить проблему прежде, чем сервис перейдет в проблемное состояние типа HARD. Но, что будет, в случае, если сервис все же перейдет в проблемное состояние типа HARD и предусмотренная последняя перезагрузка не поможет? Именно на этот случай был реализован защитный механизм, который предотвращает непрерывное выполнение команды обработчика событий. Другими словами команда обработчика событий будет выполнена только в том случае, если сервис впервые оказался в проблемном состоянии типа HARD.
Это - все! Обработчики событий довольно просто написать и реализовать, так что пробуйте, экспериментируйте и радуйтесь тому, что у вас получится. :)

Читать далее...

Почему Icinga?

Проект Nagios все больше уходит в сторону коммерции и при этом крайне медленно развивается... Многие полезные, а иногда просто необходимые, функции остаются нереализованными годами, несмотря на многочисленные просьбы пользователей. Отчасти на этой почве и был создан проект Icinga (более подробно об этом можно прочитать на официальном сайте проекта http://www.icinga.org/).

Ввиду того, что проект Icinga активно развивается и имеет все шансы вытеснить Nagios, я решил потрудиться над переводом его документации на русский язык.

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

Перевод начну с самого вкусненького, с раздела Advanced Topics, поскольку в Интернете можно найти массу статей о базовой настройке Nagios, а вот по продвинутой настройке - нет.

Совсем кратко о себе и о Nagios:
Наше знакомство произошло более 5 лет назад (с тех пор никак не можем расстаться). Я не сильно люблю коммерческие системы мониторинга (хоть и приходится с ними работать) ввиду их "негибкости". Собственно, именно гибкостью и возможностью мониторить все и вся Nagios завоевал мое сердце. :) 

Все материалы, представленные в данном блоге, являются интеллектуальной собственностью автора. Если будете "копипастить", пожалуйста, делайте ссылки на оригинал, уважайте труд автора.

Все права защищены :)
Читать далее...