Nagios vs Zabbix 2.2: семь лет верой и правдой, и всё-таки уходим

На Nagios сидим с 2006 года. Сначала это был просто набор check-скриптов и полтора десятка хостов, постепенно выросло до нескольких сотен. Конфиги хранятся в git, шаблоны самописные через define host/service/hostgroup, алерты уходят на почту и через PagerDuty-подобную схему через скрипт. Работает. Но работает примерно как карбюраторный двигатель: надёжно и без лишних вопросов, если знаешь как крутить.

Два года назад попробовали Zabbix 2.0 на двух клиентах - тогда оценили LLD, но интерфейс был всё ещё деревянным, а кривая входа довольно крутая. Оставили Nagios как основной.

Теперь вышел Zabbix 2.2. Решили дать ещё один честный шанс.

Что изменилось с 2.0

Главное, что бросается в глаза - интерфейс перестал быть наказанием. Не то чтобы это теперь красота, но навигация стала логичной: дашборд, hosts, latest data, triggers - всё находится без курения вики. Фильтры на экране проблем работают быстро. Графики строятся прямо в браузере без лишних кликов.

Авто-обнаружение хостов - network discovery и авто-регистрация агентов - работает заметно лучше. Агент при старте сам регистрируется на сервере, попадает в нужную группу по regexp-правилу в имени хоста, получает шаблон. В Nagios для этого нужен был Puppet или chef-solo, который раскидывал конфиги и перезапускал nagios. Здесь это встроено.

Как мигрировали

Взяли двух клиентов на сопровождении: один - Windows-парк офисного клиента на 60 хостов, второй - смешанная Linux/Windows инфраструктура с несколькими серверами и сетевым оборудованием. Разные случаи - интересно сравнить.

Windows-клиент. Установили zabbix-agent на все машины через GPO (файл дистрибутива в SYSVOL, политика запуска msi, ключи в реестре через Group Policy Preferences). Подняли шаблон Template OS Windows, поправили пороги под реальную нагрузку клиента. Авто-регистрация сработала: машины появились на сервере по мере того как агенты стартовали. На весь парк ушёл день - в Nagios такое занимало три.

Linux/сеть. Здесь интереснее. SNMP-мониторинг сетевого оборудования подключается через встроенные шаблоны Template Net Cisco IOS и похожие - LLD сам обнаруживает интерфейсы и строит графики трафика. В Nagios это делалось через check_snmp и ручное перечисление интерфейсов или через check_mk, который отдельный зоопарк. Тут всё в одном месте.

Что не сошлось сразу. Триггеры Zabbix - это выражения вида {host:key.function(period)}>threshold. После nagios-синтаксиса кажется непривычным, но через день-два привыкаешь. Основная ловушка - пороги по умолчанию в шаблонах не всегда разумные: например, CPU usage >85% на 5 минут генерирует срабатывание на 1С-серверах в пиковое время почти всегда. Нужно адаптировать.

Escalation в Nagios настраивался через define escalation в конфигах - муторно, но гибко. В Zabbix 2.2 это через action/operation в веб-интерфейсе, и это действительно удобнее: логика «если проблема не закрыта за N минут - отправить ещё кому-то» настраивается в несколько кликов.

Что с Nagios теперь

Не выбросили. На крупном клиенте, где конфигурация Nagios строилась несколько лет и отполирована до блеска, менять нет смысла. Там check_mk с inventory-модулем делает похожую работу по авто-обнаружению, и люди с ним давно работают.

Но для новых клиентов или там, где надо быстро развернуть мониторинг с нормальными графиками - Zabbix 2.2 выглядит рабочим вариантом. Встроенная визуализация без Cacti как отдельного сервиса - это уже само по себе аргумент.

Нескучаем по check_mk - как и обещали себе два года назад. Посмотрим, как оно на практике через пару месяцев с реальной нагрузкой.