Nagios 3.0 в production: мигрируем конфиги и наконец-то видим SLA и события в одной системе

Nagios 3.0.0 вышел в первых числах марта. Мы ждали этого с января, когда разбирали changelog бета-версии и составляли список того, что хотим от нового релиза. Финальная версия оказалась именно тем, что обещали - без сюрпризов в плохую сторону. За прошедшую неделю мы перенесли production-конфиги нескольких клиентских инсталляций и готовы рассказать, как это прошло.

Откуда стартовали

Наш Nagios 2.x вырос органически за несколько лет. Первоначальная установка в 2005-м была чистой и аккуратной. За три года поверх неё наросло всё что бывает: добавленные на скорую руку хосты, скопированные блоки с минимальными правками, шаблоны которые не совсем шаблоны, и несколько файлов конфигурации с комментарием «не трогать без необходимости». Классика.

При этом мониторинг работал: алерты приходили, инциденты ловились. Но SLA-метрики - время доступности сервисов, статистику инцидентов за период - мы считали отдельно, вручную или полуавтоматически. В Nagios 2.x есть отчёты по availability, но когда конфигурация криво описывает зависимости, отчёт показывает одно, а реальность - другое. Отдельный коммутатор упал - Nagios честно зафиксировал десять инцидентов вместо одного, и availability пяти серверов упала в отчёте, хотя виноват был один узел сети.

Nagios 3.0 это исправляет - но только если правильно описать конфиги.

Как переносили: не апгрейд, а переписывание

Мы сознательно не пошли по пути «обновить пакет, поправить что сломалось». Вместо этого написали конфиги заново, используя возможности 3.0 с нуля. Это заняло больше времени, зато результат - конфигурация, которую можно читать и понимать, а не расшифровывать.

Структура, к которой пришли, выглядит так:

Базовые шаблоны - generic-host и generic-service с общими параметрами: интервалы проверок, периоды уведомлений, контакты. Никаких конкретных хостов, только настройки по умолчанию.

Шаблоны по классам - linux-server, windows-server, network-switch, ups. Каждый наследует generic-host и переопределяет то, что специфично для класса: набор проверок, временные пороги, специфичные контакты. В Nagios 2.x это приходилось эмулировать через hostgroups и отдельные определения сервисов - теперь это честное наследование с use linux-server.

Custom variables на каждом хосте - _RACK, _SWITCH_PARENT, _CLIENT, _SLA_TIER. Последняя переменная - ключевая для нас: она определяет, к какому уровню SLA относится хост. В командах уведомлений мы теперь используем $_HOSTSLA_TIER$ чтобы в теле алерта сразу было видно, насколько критичен объект. Раньше эту информацию приходилось держать в голове или в отдельной таблице.

Дерево зависимостей - это потребовало больше всего времени, но оно того стоило. Для каждого коммутатора мы прописали зависимости хостов за ним. Теперь если коммутатор недоступен, Nagios не рассылает алерты по всем серверам за ним - он присылает один алерт по коммутатору и помечает зависимые хосты как unreachable, а не down. В отчётах это разделение принципиально важно: инцидент один, а не одиннадцать.

Что не перенеслось гладко

Несколько вещей потребовали внимания.

Формат define host в Nagios 3.0 стал строже в части наследования: если у дочернего объекта есть параметр, которого нет в шаблоне, и этот параметр не является стандартным - Nagios 3.0 при старте ругается. Nagios 2.x молча игнорировал. Пришлось пройтись по всем нестандартным конфигам и либо вынести параметры в custom variables, либо убрать лишнее.

Некоторые плагины из nagios-plugins 1.4.x работают некорректно с новым форматом вывода, который ожидает Nagios 3.0. Проблема не массовая, но несколько самописных скриптов пришлось подправить: добавить корректный perfdata-формат в вывод, который Nagios 3.0 теперь умеет парсить. Это полезное изменение, но внезапное.

SLA-метрики без отдельной системы

Главный практический результат, который мы наблюдаем уже сейчас - это availability reports в Nagios 3.0, которые наконец-то считают правильно. Когда зависимости хостов описаны честно, отчёт по availability конкретного сервера не включает в себя время, когда он был unreachable из-за проблем на вышестоящем сетевом оборудовании.

Для сопровождения инфраструктуры это важно: клиент видит отчёт, где чётко разделены «сервис был недоступен по своей вине» и «сервис был недоступен из-за сетевой проблемы». Раньше мы делали эту разбивку вручную после каждого инцидента. Теперь Nagios делает её автоматически - при условии что конфиги правильные.

Это не значит что больше не надо ничего руками. SLA-отчётность всё равно требует интерпретации: Nagios не знает, было ли плановое обслуживание согласовано или нет, не знает бизнес-контекст инцидента. Но сырые данные теперь из одного источника и считаются корректно - и это уже принципиальная разница по сравнению с тем, что было.

Где сейчас

Три клиентских инсталляции перенесены полностью, ещё две - на этой неделе. Тестового периода как такового не было: мы прогоняли конфиги через nagios -v на новой версии ещё до снятия production-трафика, и старт прошёл без неожиданностей.

Zabbix 1.6, который мы смотрели в феврале, пока остаётся на стенде. После перехода на Nagios 3.0 очевидного смысла в миграции нет - новая конфигурация стала именно такой, какой должна была быть.