Пишем свой плагин nagios
Плагины – это одна из самых сильных сторон системы мониторинга nagios. Для мониторинга базовых служб и параметров системы в комплекте установки уже есть большой набор плагинов. Если нужного плагина среди базовых нет, то можно поискать на сайтах exchange.nagios.org и monitoringexchange.org. Или написать свой плагин.
Теория работы плагинов nagios
Фактически плагин nagios – это обычная программа, которая взаимодействует с системой мониторинга через коды возврата и стандартного вывода. Коды возврата сообщают nagios о результате проверки, а из стандартного вывода формируется сообщение для web интерфейса. Со стандартным выводом все несколько сложнее, но сперва расскажу про коды возврата. Всего есть четыре кода возврата, которые может передать плагин в систему мониторинга:
0 – OK, т.е. проверка выполнена удачно и все работает как нужно.
1 – WARNING, проверка выполнена успешно, но проверяемая служба выдает показатели, превышающие порог нормальной работы.
2 – CRITICAL, проверка выполнена, но проверяемая служба не работает, или выдает значения, превышающие критический порог.
3 – UNKNOWN, такой код возврата говорит о невозможности плагином выполнить проверку. Причин для этого может быть несколько, например были введены неверные аргументы для плагина проверки или плагин не может создать какой-то дочерний процесс, открыть tcp сокет и т.п.
Один из этих кодов возврата плагин должен вернуть в любом случае. Кроме того плагин должен вывести что-то в стандартный вывод. Причем есть несколько вариантов. В самом простом варианте это должна быть просто одна строка, например:
DISK OK – free space: / 3326 MB (56%);
Этот вывод будет показан в web интерфейсе. Кроме описания произведенной проверки и ее показателей, можно выводить статистику. для разделения вывода в web интерфейс и статистики используется символ | . Формат статистики:
‘название’=значение[размерность];[warn];[crit];[min];[max]
название – текстовое обозначение выводимой величины, например /, или ‘Disk /’. Замечу, что кавычки в названии требуются, только при использовании в нем пробела, знака равно или кавычек.
значение – результат проверки.
размерность – размерность не указывается для значений, показывающих число процессов, пользователей и т.п. Если значение в процентах, то и размерность нужно указать, как %. Аналогично для времени (s), размеров данных (B, KB, MB, TB). Для постоянно увеличивающихся счетчиков используется размерность c.
warn – порог предупреждения
crit – порог критического состояния
min и max - допустимые минимальное и максимальное значения. Для размерности % указывать их не нужно понятно почему.
Можно выводить несколько параметров через пробел. Т.е. получается что-то такое:
DISKS OK – free space: / 3326 MB (56%); /home 184053 MB (27%) | /=2643MB;5948;5958;0;5968 /home=69357MB;253404;253409;0;253414
Кроме того есть третий вариант, который работает в nagios 3.x. Помимо сообщения и статистики можно выводить длинное описание, еще несколько строк, как показано вот в этом примере:
DISK OK – free space: / 3326 MB (56%); | /=2643MB;5948;5958;0;5968
/ 15272 MB (77%);
/boot 68 MB (69%);
/home 69357 MB (27%);
/var/log 819 MB (84%); | /boot=68MB;88;93;0;98
/home=69357MB;253404;253409;0;253414
/var/log=818MB;970;975;0;980
Красным выделено сообщение, оранжевым статистика и синем длинное описание. Помните, я говорил, что сообщение выводится в web интерфейс, а тогда где используется статистика и длинное описание? На самом деле все несколько сложнее. Для обработка каждого из типов вывода используется отдельный макрос:
| Макрос | Значение |
|---|---|
| $SERVICEOUTPUT$ | DISK OK – free space: / 3326 MB (56%); |
| $SERVICEPERFDATA$ | /=2643MB;5948;5958;0;5968 /boot=68MB;88;93;0;98 /home=69357MB;253404;253409;0;253414 /var/log=818MB;970;975;0;980 |
| $LONGSERVICEOUTPUT$ | / 15272 MB (77%);\n/boot 68 MB (69%);\n/var/log 819 MB (84%); |
Например статистику можно использовать для построения графиков через команду service_perfdata_command.
Теперь пожалуй с теории покончено, осталось только сказать, что в nagios есть механизм защиты от вывода слишком большого объема информации плагином, nagios прочитает только 4КБ данные, все остальное будет отброшено.
Несколько советов о практике написания плагинов
Чтобы запустить проверку, т.е. наш плагин, на удаленном сервере нужна некая служба, которая получает команды на запуск плагина от сервера nagios и отдает ему результат проверки. Различные варианты реализации такой службы я бы хотел вынести в отдельную статью, а сейчас давайте поговорим о другой проблеме.
Многие проверки, например проверка состояния raid массива, требует прав суперпользователя. Т.е. у нас есть внешняя служба на сервер, которой с одной стороны очень не хочется давать права суперпользователя, а с другой проверки, которым эти права суперпользователя нужны!
Есть два наиболее часто используемых варианта запуска на удаленном сервере плагина:
1) Плагин check_by_ssh умеет запускать на удаленном сервере заданную команду, т.е. на сервере nagios запускается плагин check_by_ssh, которому в качестве параметров передается имя проверяемого хоста и команду, которую нужно запустить.
2) Служба NRPE, на проверяемом сервере запускается служба NRPE, в ее настройках прописаны команды, которые может “попросить” выполнить сервера nagios. На стороне сервера проверка выполняется аналогично варианту с SSH, вызывается плагин check_by_nrpe с параметрами хоста и имени запускаемой команды.
Теперь вернемся к нашей проблеме, нам нужно запустить проверку с правами суперпользователя.
Вариант первый – путь камикадзе. Запускаем службу nrpe от имени root или разрешаем заход по ключу root с сервера nagios. Проблема решена, можно запускать любой плагин с правами суперпользователя. Теперь рассмотрим проблемы с безопасностью, который возникают при таком решении. Запуск любой внешней службы с правами суперпользователя всегда потенциально опасен, если в ней есть критическая уязвимость, то получить после удачного эксплойда права nobody и права root – это две большие разницы. В принципе при жесткой настройке правил фаервола для nrpe, такой вариант имеет права на жизнь, но с точки зрения системного подхода к обеспечению безопасности это явный fail. Для check_by_ssh вроде бы такой проблемы нет. Но подумайте вот о чем, если сервера nagios будет взломан, то с большой вероятностью злоумышленник получит доступ на все остальные ваши сервера!
Вариант второй – sudo. Данный вариант уже намного лучше. На проверяемом сервере создается пользователь nagios, под которым запускается nrpe или по ключу которого заходит по ssh сервер nagios. В sudo в настройках прописаны правила запуска плагинов проверки для пользователя nagios. Такой вариант намного лучше с точки зрения безопасности, но в данном варианте атака может быть направлена на запускаемый плагин. Атака маловероятная, но возможная. При грамотной настройке фаервола и прочих мерах безопасности данный вариант наиболее часто используется на практике.
Вариант третий – разделение логики проверки на собственно проверку и получение данных сервером nagios. Т.е. плагин, который мы пишем имеет два варианта запуска. В одном он выполняет проверку с правами root и сохраняет результат в какой-то файл. Права на файл выставляются так, чтобы пользователь, от имени которого запускаются проверки, мог прочитать этот файл. Эта проверка запускается через cron. Второй же вариант запуска нужен для чтения фала с результатами проверки. Из нюансов – нужно помнить, что плагин должен уметь проверять время создания файла, так чтобы не получилось, что проверка по какой-то причине давно не работает, а плагин раз за разом читает давно созданный файл и сообщает, что все ОК. Вариант с разделенной логикой наиболее безопасен, но распространен не очень сильно, так как под него придется переписывать все распространенные плагины.
Вот наверное и все, что нужно для начала написания своего плагина.
|
|