Zabbix 1.6: перевели мониторинг крупного клиента с Nagios

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

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

Nagios сам по себе нормальный инструмент. Проблема в том, что конфигурация у него текстовая, иерархическая, и на большой инфраструктуре это превращается в набор директорий с .cfg-файлами, которые нужно синхронизировать руками, перезагружать демон после каждого изменения и молиться, что в синтаксисе не опечатка. Плюс графики - отдельно, через Cacti и RRDtool. И то, и другое работает, но это два отдельных инструмента, две точки отказа, две точки настройки.

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

Что изменилось в Zabbix 1.6

Предыдущие версии Zabbix мы смотрели, но без энтузиазма - интерфейс был тяжеловатым, агент иногда капризничал. В 1.6 несколько вещей выправили:

• Веб-интерфейс стал заметно отзывчивее. Не революция, но навигация и настройка стали комфортнее. Шаблоны, триггеры, элементы данных - всё из браузера, без правки конфигов на сервере.
• Авто-обнаружение хостов (network discovery). Задаёшь диапазон IP, агент или SNMP-коммьюнити - Zabbix сам находит устройства и добавляет по заданному правилу. Это не идеальная магия: иногда находит лишнее, иногда нужно подправить правило. Но 80% хостов добавились без ручного труда.
• Встроенные графики. Не надо Cacti. Каждый item в Zabbix по умолчанию собирает историю и умеет рисовать из неё график прямо в интерфейсе. Можно строить составные графики, накладывать несколько метрик.

Как переходили

Мы не выкинули Nagios за один день. Сначала поставили Zabbix рядом, перенесли хосты в новые шаблоны, неделю сверяли алерты: если Nagios видит проблему - Zabbix тоже должен видеть. Расхождений было немного, в основном из-за разной логики таймаутов на ICMP-проверках.

Авто-обнаружение настроили по диапазонам подсетей клиента. Прописали несколько правил: хосты с открытым 10050 (zabbix-agent) идут в один шаблон, устройства с SNMP - в другой. Сетевое оборудование определилось через SNMP sysOID и попало в отдельную группу. Cisco-свитчи, которые мы разбирали отдельно в аудите сети, покрылись мониторингом за час.

Zabbix-агенты поставили через групповые политики на Windows-хостах и через shell-скрипт с authorized_keys на Linux. Настройка агента минимальная - указать адрес Zabbix-сервера, hostname, и он начинает отчитываться. Пассивный режим (сервер опрашивает агента) работал без проблем за NAT.

Где Nagios остался

Несколько специфичных проверок перенести не получилось без лишней возни: одна самописная проверка на Perl, которая дёргает внутренний API клиента, и пара check_*-плагинов, для которых в Zabbix нужно было писать внешние скрипты. Решили не трогать - Nagios отправляет по этим проверкам алерты на почту, этого достаточно. Zabbix закрыл всё остальное.

Попытка тащить Nagios-плагины напрямую через UserParameter в Zabbix сработала для простых случаев, но для плагинов с зависимостями поднять окружение было дороже, чем оставить Nagios на этих проверках.

Что в итоге

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

Cacti отключили полностью. Nagios держим для двух-трёх специфичных проверок, и это нормально - не стоит выбрасывать работающее ради принципа.

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