Nagios: обоснование выбора — Fastenv

Fastenv - системное администрирование от профессионалов индустрии. Работаем с linux, уважаем opensource.

Nagios: обоснование выбора
Сложность: Низкая | Автор: fastenv | April 30, 2016

Сегодня существует множество разнообразных систем мониторинга и регулярно появляются новые. Мы, в fastenv, этим обстоятельством удивлены. Ведь великолепному Nagios уже более 15 лет! В рамках данной статьи хочется мотивировать читателя выбрать именно его для своих задач. А так же начать ему посвященный цикл.

Мифы

Первым делом развеем пару мифов.

Миф №1. Нагиус не развивается

Нагиус взрослый проект, который уже реализовал почти всё, что может потребоваться при решении задачи мониторинга. Им нет необходимости выпускать новые релизы раз в месяц. Стабильные релизы выходят раз в 6-12 месяцев. В тоже время коммиты в их git репозиторий идут регулярно. Последний — менее одного дня назад на момент написания этих строк. Иными словами, нагиус здоров и бодрствует!

Миф №2. Сообщество мертво

Действительно, глядя на список плагинов может сложиться впечатление, что многие из них устарели, не рабочие, а новые почти никто не пишет. Дело вот в чем. Nagios имеет очень простое api взаимодействия core<->plugin, которое совместимо между всеми его версиями. Более того, это api взяли на вооружение многочисленные его форки, что делает их плагины так же пригодными для нагиуса. В итоге, с одной стороны, некогда написанный под вторую версию плагин остается рабочим и под четвертую. С другой — множество плагинов пишется под форки. Вот их неполный список: icinga, naemon, shinken, op5.

 

Концепция

Нагиус стремится соответствовать лучшим традициям unix-style. Это инструмент, который делает только свое дело и, поверьте, справляется он очень хорошо. Нагиус — это система сбора метрик и формирования алертов. Всё. Хотите графики? Нету. Хотите хранить данные? Извините. Управление конфигурацией? Конечно нет.
Так в чём же смысл?

Конфиги

Настройка нагиуса представляет из себя большей частью описание объектов мониторинга. Ключевое свойство последних — наследование. Объект может унаследовать как один, так и несколько шаблонов, в каждом из которых можно добавить или переопределить какое-то свойство. В чём удобство? Покажем на примере. У Вас имеется три датацентра, в каждом ДЦ имеется сетевое обрудование, linux и windows сервера. Задача — лаконично настроить мониторинг.

  1. В nagios.cfg добавим:
    cfg_dir=/home/nagios/settings/datacenters

    С этого момента нагиус начнет рекурсивно просматривать все директории в datacenters и искать *.cfg. Каждый такой файл будет обработан.

  2. Создадим каталоги dc-1 dc-2 dc-3 dc-all:
    mkdir -pv /home/nagios/settings/datacenters/dc-{1,2,3,all}
  3. Общие настройки поместим в dc-all.
    1. Опишем группы хостов и сервисов:
      cat > groups.cfg <<"EOFF"
      define hostgroup{
              hostgroup_name                  Dc-all-hosts
              alias                           All servers
              hostgroup_members               dc-1-hosts,dc-2-hosts,dc-3-hosts # Эти группы будут определены для каждого dc
      }
       
      define servicegroup{
              servicegroup_name               Dc-all-services
              alias                           All services
              servicegroup_members            dc-1-services,dc-2-services,dc-3-services
      }
      EOFF
    2. Опишем настройки для хостов и сервисов:
      cat > templates.cfg <<"EOFF"
      define host{
              name                            dc-common-host
              use                             generic-host
              check_period                    24x7
              check_interval                  5
              check_command                   check-host-alive
              contact_groups                  fastenv-team
              register                        0
      }
       
      define host{
              name                            dc-net-host
              use                             dc-common-host
              check_interval                  0.1 # Нет жизни без сети..
              register                        0
      }
       
      define service{
              name                            dc-common-service 
      	use				generic-service
      	register                        0
      	notification_period		24x7
      	notification_interval		30
      	max_check_attempts		3
      	check_interval			1
      	contact_groups			fastenv-team
      }
      EOFF

      Рассмотрим определение сервиса. Ключевое слово use наследует стандартный шаблон generic-service, ключевое слово register информирует, что это всего лишь шаблон, а не итоговый объект. Далее мы добавили самые общие параметры:

      1. Круглосуточно информировать.
      2. Уведомлять повторно через 30 минут.
      3. Считать сервис упавшим после 3 провалившихся проверок.
      4. Установить интервал между проверками в одну минуту.
      5. Сообщать команде фастенва.)
  4. Поговорим теперь о том, как будем настраивать каждый dc:
    1. Нам потребуется создать группы хостов dc-*-hosts. Для удобства можно создать еще подгруппы для windows, linux и net хостов.
    2. Следующим шагом создадим шаблон dc-*-service с индивидуальными настройками для датацентра. Он унаследует dc-common-service, доопределит hostgroup_name(принадлежность к группе хостов dc) и что-нибудь еще.
  5. Концептуально все готово для создания проверок:
    1. Я хочу проверять 80-й порт на всех хостах!
        Нет проблем, определяем в dc-all:

        define service{
        	use				dc-common-service
        	host_name			localhost
        	service_description		Check 80 port
        	hostgroup_name			Dc-all-hosts
        	check_command			check_port!80
        }
    2. Я хочу проверять 443-й порт везде, кроме dc3!
        Нет проблем, определим в dc-all:

        define service{
        	use				dc-common-service
        	host_name			localhost
        	service_description		Check 443 port
        	hostgroup_name			Dc-all-hosts,!dc-3-hosts
        	check_command			check_port!443
        }
    3. В dc2 для всех windows хостов проверять порт 3389:
        Определим в dc-2:

        define service{
        	use				dc-2-service
        	host_name			win1-dc-2-host
        	service_description		Check 3389 port
        	hostgroup_name			dc-2-windows-hosts
        	check_command			check_port!3389
        }

    Что главное хотелось донести. Сопровождение нагиуса тем проще и быстрее, чем лучше продумана архитектура мониторинга. Ну а при работе с ним вы не почувствуете скованности, т.к. за 15 лет предусмотрели почти всё.)

Советы по ведению конфига

  1. Храните все файлы в гите.
  2. Создайте каталоги по логическому назначению. Хорошая идея делать симлинки в каталог, который подгружает nagios.
  3. Достаточно гранулируйте шаблоны.
  4. Настройте зависимости. Предположим, в рамках нашего примера, мы хотим проверять 443 порт в dc-2 только если доступен 80-й порт в dc-1.
      Нет проблем. Определим в dc-2:

      define servicedependency{
              hostgroup_name                  dc-2-hosts
              service_description             Check 443 port
              dependent_service_description   Check 80 port
              dependent_hostgroup_name        dc-1-hosts
              execution_failure_criteria      c
              notification_failure_criteria   c,w,u
      }

Api проверок

Апи выдержано в концепции минимализма. Существует всего 4 статуса: OK, WARNING, CRITICAL и UNKNOWN. Им соответствуют просто коды завершения плагина: 0, 1, 2 и >2. Если плагин хочет вернуть какое-то сообщение, то он должен сформировать на стандартный выход:

Some text | data=1

Расположенное после вертикальной черты — называется perfdata. Это опциональные данные, которые можно обработать на стороне сервера. Как и полагается в нагиусе, команду обработки perfdata следует сперва задать.
Напишем простейший плагин:

cat > check_admins.sh <<"EOFF"
#!/bin/bash
 
echo "Fastenv is working | status=1"
exit 0
EOFF
    Мы работаем 24×7.)

Требования

Сам сервер очень легковесный. В большинстве установок ему хватит 1 ядра и 256 мегабайт памяти. Для запуска проверок на самих хостах в общем случае потребуется установить nrpe сервер. Если же говорить о мониторинге unix хостов, то все проверки можно запускать по ssh используя стандартный «транспортный» плагин check_by_ssh. В таком случае со стороны цели вообще никаких настроек может не потребоваться.
В следующей статье мы поговорим об этом подробнее и покажем, как силами нагиуса можно настроить деплой своих плагинов.

Но как можно жить без графиков?

Действительно, в наш век рюшек и свистелок больших данных, сложно представить систему наблюдения за инфраструктурой без визуализации и хранения истории.
В этом вопросе разработчики строго следуют своей концепции. На стороне сервера нет никакой системы складирования данных, но сделаны все необходимые верёвочки для интеграции. Но давайте обо всём по порядку.
В первую очередь отметим, что нагиус все же хранит историю алертов. Она пишется в специальный status-лог, по которому из веб интерфейса можно сформировать отчет.
Теперь займемся интеграцией. Как уже говорилось, плагин вправе вернуть сообщение специального формата:

| var1=1 .. varN=k

которое называется perfomance data. На стороне нагиуса можно описать команду, которая будет выполняться всякий раз, как плагин вернул данные. Для удобства сервер предоставляет множество информации в специальных переменных, которую можно использовать для дальнейшей обработки.
Делается это примерно так:

  1. Определяем команду, которая будет обрабатывать perfdata:
    define command{
            command_name    fastenv-simple-perfdata
            command_line    /usr/bin/printf "%b" "$HOSTNAME$:$SERVICEDESC$:$SERVICESTATE$:$SERVICEPERFDATA$\n" >> /home/nagios/perfdata.log
    }

    Как Вы понимаете, тут можно сразу писть в mysql, постить в твиттер или делать что-то похожее. Мы же просто пишем в лог.

  2. Инструктируем нагиус, какой именно командой требуется обрабатывать данные сервиса(nagios.cfg):
    service_perfdata_file_processing_command=fastenv-simple-perfdata
  3. Наконец включаем этот функционал(nagios.cfg):
    process_performance_data=1

С хранением, полагаю, разобрались.

Полон простоты и механизм отображения. Для этого в настрйках сервиса задается параметр action_url:

action_url                      http://graph/render?host=$HOST$..

Иными словами Вы описываете ссылку в которой нагиус подставит связанные с сервисом переменные. Пройдя по ней Ваш любимый бекенд отрисует нужный график.

Вывод

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

  1. Rrd + pnp4nagios.
  2. Graphite + graphios.
  3. InfluxDB + nagflux.

Web интерфейс

Думаю мой читатель уже знает, чего ждать от стандартного интерфейса. Он аскетичен и не перегружен. Но что действительно важно — он не единственный. Существуют альтернативы развиваемые как командой нагиуса, так и сообществом. Хороший пример последнего — thruk.