Введение.
Выбрав Nagios в качестве системы мониторинга, получаем систему слежения за качественными характеристиками окружения и историю изменения состояний. И, если посмотреть текст сообщения пробника на данный момент и во время прошлых изменений состояния еще возможно, то данные по периодам между изменениями отсутствуют как класс. При любой более-менее активной работе с мониторингом, возникает желание просмотра истории изменений количественных характеристик тоже, что стандартный Nagios обеспечить не может. Можно, конечно, продублировать все необходимые пробники в тот же Cacti, но это как минимум дополнительные накладные расходы как на конфигурирование так и на машину с поллером. К счастью, Nagios умеет переложить это на плечи пользователя, обеспечивая механизм так называемых «данных производительности» (performance data). В данной статье рассматривается одно из решений по сбору и визуализации полученных данных – Pnp4Nagios.
Данные производительности
Состояние пробника дополненное данными производительности выглядит примерно так:
Способ доставки и требования к данным подробно расписаны в документации, нам же в данном случае важно, что Nagios умеет как взять данные из вывода плагина, так и отдать их каким-либо внешним утилитам, ибо наличие дополнительной строчки в веб интерфейсе хоть и вносит некое разнообразие, однако ж пользы проносит немного :).
Внешние утилиты
Утилит для обработки performance data [и превращения их в графики] перечисленных только на exchange.nagios.org/directory/Addons/Graphing-and-Trending около 20ти. Несмотря на то, что делают они вроде бы одно и то же, они всё же различаются. Когда я выбирал тулзу для себя, руководствовался примерно следующим списком характеристик:
- Интерфейс. Кроме шуток – посмотрите на то, что представлено в списке Graphing-and-Trending дополнений – почти все выглядят бледновато, если не сказать убого. После Cacti хотелось чтобы была как минимум возможность сделать графику Zoom. Ну и шаблоны отображения графиков.
- Способ хранения статистики – мог бы быть на первом месте если б не почти поголовное увлечение RRD, среди этого выделяется www.opmon.org/documentation, хранит данные в Mysql базе, дальше я на него и не смотрел, хватило и Zabbix’а с его хранением данных в базе.
- Управление конфигурацией – после XML’я Cacti хотелось чего-то человеческого.
Pnp4nagios
Рассмотрим, что предлагает нам Pnp4nagios.
- Интерфейс. Простое сравнение скриншотов Pnp4Nagios с NagiosGrapher’овскими, явно не в пользу последнего.
pnp4nagios
NagiosGraph
В частности, в Pnp4Nagios можно делать приближение, просмотр графиков по заданным периодам, в том числе выбор интервала дат в календаре; экспортировать график в виде pdf файла, файл соотвественно можно переслать не мучаясь вставкой картинок в письмо; добавить график в «корзину» для быстрого перехода в последующем; перейти к списку алертов в Nagios за выбранный промежуток времени. В дополнение к этому есть средство группировки графиков от разных хостов – так называемые «страницы». Поддерживается локализация, что впрочем не факт что плюс :) - Способ хранения статистики.
Особо акцентировать внимание неначем, разве, что Pnp4Nagios поддерживает RRDCached — пригодится в больших инсталляциях. О пользе RRDCached и iohell подробно написано здесь - Конфигурация.
Конфигурирование Pnp4Nagios, конечно, не такое гибкое как у того же Zabbix’а, но зато не приходит OOM-Killer ;)
Самая заметная часть, внешний вид графиков, определяется шаблонами. В комплекте идёт некоторое количество стандартных шаблонов. Для своих собственных проверок можно сделать отдельный шаблон, если стандартный не устраивает. Шаблоны представляют собой php скрипты выполняемые через include и по сути должны сформировать командную строку для rrdtool’а. Во время обработки шаблона доступны экспортируемые Nagios’ом внутренние данные, например время когда хост последний раз был жив ( $LASTHOSTUP$ ), что позволяет выводить графики почти любой информативности. Шаблоны определяются из имени команды, причем поддерживается выделение значимой части, т.е. если у вас наличествуют проверки при помощи check_nrpe, то можно сконфигурировать выбор шаблона таким образом, что check_nrpe будет отброшено.
Параметры, задаваемые при создании rrd файлов, так же могут быть изменены в шаблонах. Поддерживаемые опции включают тип данных (datasource) – GAUGE, COUNTER, DERIVE; использовать ограничения на минимальное и/или максимальное значение что полезно для устранения «протуберанцев» для счетчиков типа COUNTER/DERIVE в случае перезагрузки сервера/рестарта демона.
Обработка данных
Поддерживаются 3 вида обработки performance data:
- Синхронный режим. Команда обработки данных process_perfdata.pl вызывается на каждую проверку. Самый простой в конфигурировании ( отредактировать 4 строчки :) но и самый «плохой» — пока не завершится данный скрипт, работа Nagios будет заблокирована, что при большом количестве проверок может стать заметным из-за дисковой подсистемы. Например на ненагруженном хосте можно наблюдать:
2009-12-23 20:41:54 [28100] [2] RRDs::update /var/lib/pnp4nagios/nginx.local/load_average.rrd 1261590114:0.00:0.00:0.00
2009-12-23 20:41:54 [28100] [2] /var/lib/pnp4nagios/nginx.local/load_average.rrd updated
2009-12-23 20:41:54 [28100] [1] PNP exiting (runtime 0.003274s) ...
На первый взгляд 3 миллисекунды это очень мало, но учитывайте что файловый ввод-вывод уходит в vmcache которого хватает чтобы держать rrdшки потому что их немного, 28 штук.
- Режим «скопом». Nagios записывает данные в файл и с определённой периодичностью вызывает скрипт process_perfdata.pl, который читает и обрабатывает весь файл целиком, что значительно быстрее чем синхронный режим, но тем не менее возможна блокировка Nagios’а на чуть бОльший период. Пример:
2009-12-23 20:28:11 [7299] [1] 83 Lines processed
2009-12-23 20:28:11 [7299] [1] /var/spool/pnp4nagios/service-perfdata-PID-7299 deleted
2009-12-23 20:28:11 [7299] [1] PNP exiting (runtime 0.118031s) ...
Одна десятая секунды уже заметнее, но всё ещё быстро, так как и в данном случае пока хватает vmcache (491 rrd files).
- «Скопом», но отдельным демоном – практически как второй способ, но вместо вызова нашего обработчика Nagios сделает перенос файлов и успокоится, а отдельно работающий демон с некоторой периодичностью проверяет нужную папку и запускает process_perfdata.pl если обнаружены файлы. Поскольку перенос файлов в пределах одной файловой системы выполняется почти мгновенно, этот способ не блокирует Nagios и может быть рекомендован для нагруженных сред.
Интеграция с веб интерфейсом Nagios
Интеграцию в веб интерфейс Nagios'а можно произвести при помощи action_url для хостов и сервисов, что позволяет a) перейти к просмотрю графиков в один клик 2) можно смотреть превьюшки графиков просто наведя указатель
Минусы
- Первый минус стандартен для всех? систем на базе RRD — нет гибкого управления набором графиков и шаблонов их отображения. Править шаблоны на php хоть и не сложно, но есть способы потратить время с большей пользой.
- Плагины Nagios'а должны поддерживать вывод performance data, что есть далеко не у всех. Для плагинов которые проверяют «счётчики» ( например трафик на интерфейсе ) очень желательно поддержка вывода минимального/максимального допустимого значения в строке performance data, иначе rrd база создастся без ограничений и будут «протуберанцы» при сбросе счётчика.
- Не то чтобы прямой, но минус, частично вытекающий из первого — Nagios/Pnp4Nagios не замена комплексу сбора статистики о состоянии системы. О том, что может претендовать на эту роль я напишу отдельно.
Ссылки:
Сайт проекта — содержит довольно внятную документацию и инструкцию по установке и настройке. При установке из пакета достаточно следовать инструкциям из /usr/share/doc/pnp4nagios/README.Debian.gz.
Доступ к исходному коду
Debian пакет pnp4nagios доступен в моем репозитарии http://repo.coolcold.org .
IRC: #pnp4nagios @ freenode
