Переезд с Nagios на Zabbix 1.9: агенты на 140 хостах, шаблоны и двойной мониторинг на переходный период

Мы используем Nagios с 2004 года. Система честная, предсказуемая, хорошо задокументированная. Но у неё есть один принципиальный изъян, который с ростом парка хостов начинает ощущаться физически: Nagios - это система алертов, а не метрик. Графики исторически делаются через Nagiosgraph или PNP4Nagios - внешние костыли поверх RRDtool, которые нужно отдельно ставить, настраивать и чинить, когда они разъезжаются с основной конфигурацией. Когда в обслуживании под сотню-полторы хостов - это начинает утомлять.

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

Что меняется архитектурно

В Nagios каждая проверка - это отдельный запуск плагина. NRPE, check_mk, custom scripts - всё это процессы, которые форкаются, что-то проверяют и умирают. Хранения метрик нет в базовом дистрибутиве.

В Zabbix агент постоянно работает на хосте, собирает метрики по расписанию и отправляет их на сервер, где они пишутся в базу (у нас MySQL). Это принципиально другая модель: метрика хранится, её можно строить графиком, делать триггеры с историческими порогами, строить агрегаты по группам хостов. Всё из коробки, без внешних RRD-обёрток.

Минус той же медали: база растёт. При 140 хостах и интервале сбора 60 секунд по 50-80 метрик на хост - это несколько миллионов строк в сутки. На MySQL с правильно настроенным housekeeper'ом это терпимо, но за базой нужно следить.

Разворачивание агентов

На Linux всё просто. Zabbix-агент есть в EPEL для CentOS/RHEL и в стандартных репозиториях Debian/Ubuntu. Пакет ставится, конфиг правится под наш сервер, сервис стартует. Конфиг минимальный: Server=, Hostname=, LogFile=. Дальше хост появляется на сервере и начинает слать данные.

На Windows ситуация чуть интереснее. Агент ставится как служба через zabbix_agentd.exe -i, конфиг тот же формат. Но нужно не забыть:

• Firewall. Windows Firewall по умолчанию блокирует входящие на порт 10050. Либо правило через GPO, либо активный режим агента (агент сам стучится на сервер). Мы выбрали активный режим для Windows-хостов - меньше мороки с firewall-правилами на каждой машине.
• Права службы. Для ряда счётчиков производительности (WMI, некоторые счётчики памяти) агенту нужны повышенные права. По умолчанию служба запускается под LocalSystem - это работает, но лучше завести отдельную учётку.
• Имя хоста. Zabbix использует Hostname из конфига для идентификации, и это должно совпадать с тем, что прописано на сервере. На Windows-хостах с FQDN в Active Directory нужно явно прописывать имя в конфиге, иначе агент присылает короткое NetBIOS-имя, а сервер ждёт FQDN.

Массовое разворачивание мы сделали через наш же Puppet - написали манифест для Linux, скрипт через GPO для Windows. Из 140 хостов 130 подняли агентов за первые двое суток, остальные десять - это изолированные площадки и один legacy-хост на Windows 2003 SP1, куда пришлось ставить руками.

Шаблоны: не повторять то, что уже сделали другие

Главное открытие при переходе с Nagios: в Zabbix не надо описывать каждый хост с нуля. Шаблоны делают большую часть работы. Мы взяли за основу стандартные шаблоны из дистрибутива (Template OS Linux, Template OS Windows) и дополнили под свои нужды.

Для Linux-хостов добавили:

• Мониторинг конкретных сервисов - nginx, PostgreSQL, OpenVPN - через net.tcp.port[] и userparameter для чтения PID-файлов.
• SMART-статус дисков через userparameter и smartmontools. Это то, чего в стандартном Nagios всегда требовало отдельного плагина.
• Нагрузку на файловые системы - стандартный шаблон покрывает /, но у клиентов есть отдельные точки монтирования для данных и логов.

Для Windows-хостов основная работа была в счётчиках производительности: очереди к дискам, доступная память (не просто объём, а Page Faults/sec), длина очереди процессора. Всё это доступно через perf_counter[] в Zabbix-агенте на Windows, и это заметно удобнее, чем тащить NRPE с check-плагинами в Nagios.

Алерты: почта и Jabber

Nagios у нас слал алерты на почту. Работало, но раздражало: письма теряются в потоке, на телефоне с мобильным клиентом плохо читаются, группировки нет.

В Zabbix алерты настраиваются через Action + Media. Мы подняли два канала:

Email - для хостов и триггеров второго уровня серьёзности (Warning, Average). Письмо формируется из шаблона, в нём имя хоста, имя триггера, текущее значение и время. На Recovery приходит отдельное письмо с пометкой RESOLVED.

Jabber - для критичных алертов (High, Disaster). Zabbix поддерживает Jabber через встроенный media type, указываешь JID сервера, логин и пароль бота, дальше работает. Мы используем корпоративный Jabber-сервер на Openfire. Сообщение короткое - имя хоста, проблема, время. На телефоне с Jabber-клиентом это приходит мгновенно и не тонет в почте.

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

Nagios как fallback

Nagios мы пока не отключили. Логика простая: новая система работает меньше двух недель на живом парке, доверия ей ещё нет в полной мере. Nagios продолжает мониторить те же хосты через NRPE - параллельно. Если Zabbix пропустит что-то важное, Nagios подстрахует.

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

Первые впечатления

Скорость реакции команды на алерты выросла - Jabber работает лучше почты. Графики метрик прямо в интерфейсе, без переключения в PNP4Nagios, сокращают время диагностики. Настройка шаблонов занимает больше времени, чем написание Nagios-конфигов, но делается один раз - потом новый хост добавляется за минуту.

Конфигурация через веб-интерфейс вместо текстовых файлов - это вопрос привычки. Текстовые файлы Nagios хорошо ложатся в git, веб-интерфейс Zabbix - нет. Экспорт/импорт XML в Zabbix есть, но это не то же самое, что git diff по конфигу. Будем смотреть, как это решается в реальной операции.