Nagios 3.0: читаем changelog бета-версии и считаем, что нас наконец-то услышали

В этом месяце мы больше смотрели на Microsoft - Windows Server 2008 RC1 занял большую часть тестового времени. Но параллельно прилетела новость, которую мы давно ждали: Nagios 3.0 вышел в финальную бету, и разработчики обещают релиз в ближайшие месяцы. Мы взяли changelog и провели вечер, читая его с пристрастием.

Спойлер: там есть несколько вещей, которые мы буквально просили у вселенной, пока разворачивали Nagios 2.x на инфраструктуре из полусотни узлов.

Почему Nagios 2.x начал раздражать

Nagios 2.x - зрелый, надёжный, работающий. Но когда количество мониторируемых хостов переваливает за определённую отметку, конфигурация превращается в тихий кошмар.

Главная боль - дублирование. Описываешь десять серверов с похожим набором проверок, и каждый раз копируешь почти одинаковые блоки с незначительными отличиями. Шаблоны в Nagios 2.x есть, но наследование там минималистичное: один уровень, без переопределения отдельных параметров в дочернем объекте. Хочешь слегка изменить один параметр у трёх хостов - приходится либо копировать, либо городить workaround через хостовые группы и отдельные команды.

Вторая боль - зависимости. Есть коммутатор, за ним пять серверов. Если коммутатор упал, Nagios исправно шлёт уведомления за каждый из пяти серверов отдельно. Технически правильно, практически - ты тонешь в алертах об одном событии. В Nagios 2.x зависимости хостов (host dependencies) формально существуют, но настраивать их на больших топологиях - занятие не для слабонервных.

Что изменилось в Nagios 3.0

Наследование шаблонов стало нормальным. В Nagios 3.0 поддерживается многоуровневое наследование с возможностью переопределять отдельные параметры на любом уровне. Можно создать базовый шаблон generic-host, от него наследовать linux-server, а уже от него - конкретный хост с переопределением одного-двух параметров. Это не революция, это то, как должно было работать с самого начала.

Custom variables. В Nagios 3.0 появились пользовательские переменные для хостов и сервисов - поля с префиксом _. Например, _RACK_SLOT 3A-12 или _OWNER infra. Эти переменные доступны в командах проверок и в уведомлениях. На практике это открывает возможность передавать контекст прямо из конфигурации в скрипты - без внешних таблиц и без хаков через communities SNMP. Мелочь, но очень практичная.

Зависимости хостов стали работать как задумано. В Nagios 3.0 логика определения недоступности через родительский хост переработана. Теперь можно описать дерево зависимостей - и если коммутатор недоступен, Nagios понимает, что серверы за ним не нужно опрашивать и уведомлять отдельно. Это не просто удобство: при мониторинге разнесённой инфраструктуры разница между «50 алертов» и «1 алерт с контекстом» - это разница между паникой и спокойной диагностикой.

Web UI переработан. Мы видели скриншоты - он стал выглядеть заметно аккуратнее. Информация на обзорной странице сгруппирована лучше, добавились фильтры. Для Nagios 2.x Web UI был скорее необходимостью, чем удобством. Посмотрим, как это ощущается в работе.

Как мы это планируем применить

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

Практически это означает:

• Базовые шаблоны для классов хостов: Linux-серверы, Windows-серверы, сетевое оборудование, принтеры.
• Промежуточные шаблоны для групп: например, все серверы за одним коммутатором наследуют зависимость от него.
• Custom variables для метаданных узла: стойка, ответственный, тип договора.
• Дерево зависимостей по топологии сети - это главное, чего сейчас не хватает.

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

Чего ждём от финального релиза

По информации из списков рассылки Nagios, финальный релиз 3.0 ожидается в первом квартале. Если changelog не соврёт и в производительности тоже будет прирост (а разработчики обещают оптимизацию цикла проверок), то обновление на нашей инфраструктуре станет приоритетом на ближайшие месяцы.

Мониторинг - это не та вещь, о которой вспоминают, пока всё работает. Зато когда что-то падает в час ночи, и ты видишь один внятный алерт вместо пятидесяти бессмысленных - это стоит потраченных вечеров на конфиги.

Для клиентов, которым мы ведём сопровождение инфраструктуры, это обновление будет прозрачным - просто мониторинг начнёт работать немного умнее.