Графики в Nagios — зачем и чем

    Введение.


    Выбрав Nagios в качестве системы мониторинга, получаем систему слежения за качественными характеристиками окружения и историю изменения состояний. И, если посмотреть текст сообщения пробника на данный момент и во время прошлых изменений состояния еще возможно, то данные по периодам между изменениями отсутствуют как класс. При любой более-менее активной работе с мониторингом, возникает желание просмотра истории изменений количественных характеристик тоже, что стандартный Nagios обеспечить не может. Можно, конечно, продублировать все необходимые пробники в тот же Cacti, но это как минимум дополнительные накладные расходы как на конфигурирование так и на машину с поллером. К счастью, Nagios умеет переложить это на плечи пользователя, обеспечивая механизм так называемых «данных производительности» (performance data). В данной статье рассматривается одно из решений по сбору и визуализации полученных данных – Pnp4Nagios.

    Данные производительности


    Состояние пробника дополненное данными производительности выглядит примерно так:
    perfdata example

    Способ доставки и требования к данным подробно расписаны в документации, нам же в данном случае важно, что Nagios умеет как взять данные из вывода плагина, так и отдать их каким-либо внешним утилитам, ибо наличие дополнительной строчки в веб интерфейсе хоть и вносит некое разнообразие, однако ж пользы проносит немного :).

    Внешние утилиты


    Утилит для обработки performance data [и превращения их в графики] перечисленных только на exchange.nagios.org/directory/Addons/Graphing-and-Trending около 20ти. Несмотря на то, что делают они вроде бы одно и то же, они всё же различаются. Когда я выбирал тулзу для себя, руководствовался примерно следующим списком характеристик:

    1. Интерфейс. Кроме шуток – посмотрите на то, что представлено в списке Graphing-and-Trending дополнений – почти все выглядят бледновато, если не сказать убого. После Cacti хотелось чтобы была как минимум возможность сделать графику Zoom. Ну и шаблоны отображения графиков.
    2. Способ хранения статистики – мог бы быть на первом месте если б не почти поголовное увлечение RRD, среди этого выделяется www.opmon.org/documentation, хранит данные в Mysql базе, дальше я на него и не смотрел, хватило и Zabbix’а с его хранением данных в базе.
    3. Управление конфигурацией – после XML’я Cacti хотелось чего-то человеческого.


    Pnp4nagios


    Рассмотрим, что предлагает нам Pnp4nagios.

    1. Интерфейс. Простое сравнение скриншотов Pnp4Nagios с NagiosGrapher’овскими, явно не в пользу последнего.

      pnp4nagios

      NagiosGraph



      В частности, в Pnp4Nagios можно делать приближение, просмотр графиков по заданным периодам, в том числе выбор интервала дат в календаре; экспортировать график в виде pdf файла, файл соотвественно можно переслать не мучаясь вставкой картинок в письмо; добавить график в «корзину» для быстрого перехода в последующем; перейти к списку алертов в Nagios за выбранный промежуток времени. В дополнение к этому есть средство группировки графиков от разных хостов – так называемые «страницы». Поддерживается локализация, что впрочем не факт что плюс :)
    2. Способ хранения статистики.
      Особо акцентировать внимание неначем, разве, что Pnp4Nagios поддерживает RRDCached — пригодится в больших инсталляциях. О пользе RRDCached и iohell подробно написано здесь
    3. Конфигурация.
      Конфигурирование Pnp4Nagios, конечно, не такое гибкое как у того же Zabbix’а, но зато не приходит OOM-Killer ;)
      Самая заметная часть, внешний вид графиков, определяется шаблонами. В комплекте идёт некоторое количество стандартных шаблонов. Для своих собственных проверок можно сделать отдельный шаблон, если стандартный не устраивает. Шаблоны представляют собой php скрипты выполняемые через include и по сути должны сформировать командную строку для rrdtool’а. Во время обработки шаблона доступны экспортируемые Nagios’ом внутренние данные, например время когда хост последний раз был жив ( $LASTHOSTUP$ ), что позволяет выводить графики почти любой информативности. Шаблоны определяются из имени команды, причем поддерживается выделение значимой части, т.е. если у вас наличествуют проверки при помощи check_nrpe, то можно сконфигурировать выбор шаблона таким образом, что check_nrpe будет отброшено.
      Параметры, задаваемые при создании rrd файлов, так же могут быть изменены в шаблонах. Поддерживаемые опции включают тип данных (datasource) – GAUGE, COUNTER, DERIVE; использовать ограничения на минимальное и/или максимальное значение что полезно для устранения «протуберанцев» для счетчиков типа COUNTER/DERIVE в случае перезагрузки сервера/рестарта демона.


    Обработка данных


    Поддерживаются 3 вида обработки performance data:
    1. Синхронный режим. Команда обработки данных 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 штук.
    2. Режим «скопом». 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).
    3. «Скопом», но отдельным демоном – практически как второй способ, но вместо вызова нашего обработчика 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
    Поделиться публикацией

    Комментарии 5

      0
      У нас стоит nagios отдельно и cacti отдельно. Сервера опрашивались по SNMP. Железка стояла далеко не мощная (это к дополнительным расходам на машину для поллера).
      Еще есть вещь удобная для мониторинга сети Network Weathermap
        0
        Нет вопросов, до какого-то предела понятно что можно жить и на одной, всё от нагрузки зависит. Другое дело что рисовать графики в одном месте, а выдавать алерты в другом несколько утомительно, как минимум в плане синхронизации.
        0
        Можно было-бы приручить Cacti брать инфу с наджиоса.
        Или был бы какой либо переходник SNMP-Сборщик инфы и хранение= а от него инфа поступала бы и в наджиос и в какти.
          0
          Инфу брать дело не хитрое, хитрое дело интеграция — список сервисов и переход на информацию по сервису (нужный урл в Нагиосе) это еще дополнительно пилить.

          Про переходник не понял мысль.
            0
            вроде плагин NPC умеет много в этом плане

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

        Самое читаемое