Сегодня существует множество разнообразных систем мониторинга и регулярно появляются новые. Мы, в 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.