Переход с Nagios Core на Icinga 2: первый взгляд на совместимость и API

У нас в управляемой инфраструктуре Nagios Core прожил дольше, чем должен был. Не потому что хорошо, а потому что работает, и трогать страшно - конфиги накапливались годами, плагинов написано несколько десятков, и вся эта конструкция держалась на нескольких людях, которые помнят, что где лежит. Когда один из клиентов попросил посмотреть на Icinga 2 - мы воспользовались случаем и разобрались что там сейчас к чему.

Откуда вообще Icinga

Icinga - это форк Nagios, который появился в 2009 году, когда сообщество устало от темпа разработки оригинала. Первая ветка (Icinga 1.x) - это, по сути, тот же Nagios с улучшенным веб-интерфейсом и несколькими дополнительными параметрами конфигурации. Полная совместимость с Nagios-плагинами, совместимость конфигов с незначительными правками, знакомая логика check_commands и escalations.

Icinga 2 - это уже другая история. Переписана с нуля, новый формат конфигурации, новая архитектура. Поддержка Nagios-плагинов осталась (они работают как команды через стандартный интерфейс), но конфиги придётся переписывать. Проект пока молодой и шероховатый - на productionиспользование сейчас смотришь с определённой долей скептицизма, но посмотреть интересно.

Что делали на стенде

Развернули оба варианта: Icinga 1.9 и Icinga 2 beta на отдельных VM с Ubuntu 12.04. Взяли реальные конфиги Nagios с одного из клиентских сегментов: около ста хостов, стандартный набор check_ping, check_ssh, check_http, несколько самописных плагинов на bash и Python.

Icinga 1.x принял конфиги почти без изменений. Пришлось поправить пару директив, которые в Icinga добавили или переименовали, но по сути это был cp -r и service icinga start. Для команды, у которой Nagios живёт пять лет - это ключевой момент: можно мигрировать, не переписывая всё сразу.

Icinga 2 потребовал переработки. Новый формат объявления объектов object Host { ... } и object Service { ... } вместо нагиосовских блоков. Логика та же, синтаксис другой. Конвертер есть, но его результат требует ручной проверки - на автопилоте не летит.

Веб-интерфейс - реальное отличие

Классический Nagios Core с CGI-интерфейсом в 2014 году выглядит как артефакт. Работает, информацию показывает, но на большом парке хостов ориентироваться неудобно, фильтрация слабая, кастомизации почти нет.

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

REST API - то, ради чего смотрят на Icinga 2

Это, пожалуй, самое интересное в Icinga 2. У Nagios есть только external command file - FIFO, в который пишешь команды в специальном формате. Работает, но интеграция с чем-либо - это ручная работа.

Icinga 2 предоставляет REST API поверх HTTP с JSON: можно программно опросить статус хоста, поставить downtime, подтвердить проблему, создать или удалить объект мониторинга. Это открывает нормальную автоматизацию - например, при деплое нового сервера через Ansible можно автоматически добавить его в мониторинг через API-вызов, без SSH на мониторинговый хост и правки конфигов вручную.

Мы потрогали API на стенде: вызовы GET /v1/objects/hosts и PUT /v1/objects/hosts/<name> работают, формат документирован. Аутентификация через basic auth с ролями. Пока API в beta, часть endpoint-ов может изменяться, но направление понятно.

Гибкость уведомлений

В Nagios уведомления - это contact, contactgroup, escalation и набор временных периодов. Всё через конфиги, никакой динамики. У Icinga 2 появилась концепция apply rules: можно описать логику назначения уведомлений через выражения с условиями вместо статического перечисления. На практике это означает, что добавление нового типа хоста или нового ответственного - это правка одного места, а не обход нескольких конфиг-файлов.

На стенде это выглядит убедительно. Насколько масштабируется на реальный парк с несколькими сотнями хостов и несколькими командами - пока вопрос открытый.

Что думаем про миграцию

Для клиента, который спрашивал, мы пришли к такому выводу:

• Icinga 1.x - это разумный шаг прямо сейчас, если хочется нормального веб-интерфейса при минимальном риске. Конфиги переезжают практически без изменений, плагины те же, понятия те же. Операционные риски минимальны.
• Icinga 2 - интересно из-за API и apply rules, но пока ранняя стадия. Для production без острой необходимости брать не стали бы - подождём пока проект наберёт больше опыта эксплуатации и стабилизирует API.

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

Параллельно у нас есть сегменты на Zabbix - там своя логика и свои плюсы, о которых отдельно. В мониторинге нет одного правильного ответа, есть контекст и компромиссы.