Icinga 2: распределённый мониторинг инфраструктуры с мастером и сателлитами

Семёнов Евгений Сергеевич, директор АйТи Фреш. Icinga 2 — глубоко недооценённая в России система мониторинга. Пока все ставят Zabbix или Prometheus+Grafana, я на нескольких проектах осознанно выбираю Icinga: её сила в жёстком стейт-машиническом подходе к инцидентам, гибкой иерархии зон и модуле Director для управления через веб-интерфейс. В этой статье покажу развёртывание мастера, сателлита на удалённой площадке, подключение агента и настройку через Icinga Director.

Почему Icinga 2 стоит выбрать

Zabbix хорош для сбора метрик и красивых графиков, Prometheus — для облачной инфраструктуры с Kubernetes. А Icinga — когда нужно надёжно, чётко и понятно: хост работает, хост сломан, сервис OK, сервис CRITICAL. Стейт-машины. Эскалации. SLA-отчёты.

Где я выбираю Icinga 2:

• Распределённые инфраструктуры с несколькими ЦОД или филиалами.
• Банки и госсектор — там любят «нагиосоподобную» парадигму и audit trail.
• Смешанные окружения Linux + Windows + сетевое оборудование.
• Необходимость глубокой кастомизации проверок — свои скрипты на bash, Python, PowerShell интегрируются тривиально.
• Когда Zabbix превращается в кашу из триггеров и хочется переписать мониторинг с чистого листа.

Архитектура: зоны и роли

Icinga 2 строится на концепции зон (Zone). Зона — это логическая группа серверов с одной ролью. Стандартная иерархия для корпоратива:

• master — главный сервер, веб-интерфейс, база данных, конфигурация.
• satellite-msk — сателлит в московском офисе, выполняет локальные проверки.
• satellite-spb — сателлит в питерском филиале.
• agent-* — агенты на конечных хостах для внутренних проверок.

Master и satellite обычно делают в HA-паре (два узла с одинаковой конфигурацией). Я всегда ставлю минимум по два сервера в каждой критичной зоне.

Установка мастера на Debian 12

# Репозиторий Icinga
curl -fsSL https://packages.icinga.com/icinga.key | sudo gpg --dearmor \
  -o /usr/share/keyrings/icinga-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] \
  https://packages.icinga.com/debian icinga-bookworm main" \
  | sudo tee /etc/apt/sources.list.d/icinga.list
sudo apt update

# Установка icinga2 и плагинов
sudo apt install -y icinga2 monitoring-plugins nagios-nrpe-plugin

# База данных (MariaDB)
sudo apt install -y mariadb-server
sudo mysql_secure_installation

# IDO-коннектор
sudo apt install -y icinga2-ido-mysql
sudo icinga2 feature enable ido-mysql

# Веб-интерфейс
sudo apt install -y icingaweb2 icingacli php-imagick

Настройка мастера

После установки запускаем мастер-сетап — он сгенерирует CA, сертификаты и базовую конфигурацию зон.

sudo icinga2 node setup --master
sudo systemctl restart icinga2

# Проверка статуса
sudo icinga2 daemon -C
sudo icinga2 object list --type Zone
sudo icinga2 object list --type Endpoint

Я всегда правлю /etc/icinga2/constants.conf сразу после установки, чтобы задать глобальные переменные окружения:

const NodeName = "icinga-master.corp.ru"
const ZoneName = "master"
const PluginDir = "/usr/lib/nagios/plugins"
const TicketSalt = "ВашСекретныйСлат32Символа"

Добавление сателлита на удалённой площадке

На сервере в Питере ставим тот же пакет icinga2, запускаем node wizard, который подключится к мастеру через CSR и получит сертификат.

# На сателлите satellite-spb.corp.ru
sudo apt install -y icinga2 monitoring-plugins
sudo icinga2 node wizard

# Отвечаем на вопросы:
# Is this agent/satellite setup? [y/N]: y
# Common name: satellite-spb
# Parent endpoint: icinga-master.corp.ru
# Parent zone: master
# Ticket (на мастере: icinga2 pki ticket --cn satellite-spb): xxx

sudo systemctl restart icinga2

На мастере в /etc/icinga2/zones.conf прописываем зону сателлита и её endpoints:

object Endpoint "satellite-spb" {
  host = "satellite-spb.corp.ru"
  port = "5665"
}

object Zone "satellite-spb" {
  endpoints = [ "satellite-spb" ]
  parent = "master"
}

После restart icinga2 на мастере сателлит появляется в веб-интерфейсе, и можно назначать на него проверки.

Icinga Director: управление через UI

Без Director Icinga настраивается через .conf файлы — это мощно, но для большой команды неудобно. Director даёт веб-UI поверх тех же объектов, с импортом из внешних источников и проверкой перед деплоем.

sudo apt install -y icinga-director
sudo mysql -u root -p
# CREATE DATABASE director CHARACTER SET 'utf8mb4';
# GRANT ALL ON director.* TO director@localhost IDENTIFIED BY 'Pass123';
# FLUSH PRIVILEGES;

# В UI: Icinga Web 2 → Configuration → Modules → director → Enable
# Configure director database, Migrate schema

В Director я всегда делаю так: шаблоны хостов (Linux, Windows, Network), шаблоны сервисов (HTTP, HTTPS, MySQL, SMTP), импорт хостов из AD по LDAP и автоматическое назначение сервисов по полю в имени хоста.

Таблица типовых проверок

Уведомления: email, Telegram, Slack

Icinga умеет отправлять уведомления любым способом через скрипты NotificationCommand. Я всегда ставлю два канала: email для всех и Telegram для критичных.

# /etc/icinga2/conf.d/notifications.conf, фрагмент
object NotificationCommand "telegram-service" {
  command = [ "/etc/icinga2/scripts/telegram-service.sh" ]
  arguments = {
    "-c" = "$telegram_chat_id$"
    "-t" = "$telegram_bot_token$"
    "-s" = "$notification.type$"
    "-h" = "$host.name$"
    "-v" = "$service.name$"
    "-o" = "$service.output$"
  }
}

apply Notification "telegram-ops" to Service {
  command = "telegram-service"
  users = [ "ops-team" ]
  types = [ Problem, Recovery ]
  assign where service.vars.priority == "critical"
  vars.telegram_bot_token = "1234567890:AAA..."
  vars.telegram_chat_id = "-1001234567890"
}

Кейс: мониторинг филиальной сети страховой

В августе 2025 обратилась страховая компания — центральный офис в Москве, 14 филиалов в регионах, в каждом по 5-20 сотрудников, выделенный сервер и сетевое оборудование. Существующий Zabbix работал из Москвы по VPN и жаловался на потери пакетов, алерты приходили криво. Нужен был мониторинг с агентами в каждом филиале, но с одним окном управления.

Развернули Icinga 2 master HA-пару в дата-центре МТС на Dell Xeon Platinum 8280 — два узла с общим MySQL Galera. В каждом филиале поставили сателлит на маленьком NUC-сервере. Агенты Icinga на всех Windows и Linux хостах. Все сервера в одной consoli, 14 изолированных зон — при обрыве связи с филиалом локальный сателлит продолжает проверки и сохраняет их, синхронизируется после восстановления линка.

• Алерты с ложной срабатываемостью упали с 20 в день до 1-2.
• Мониторится 480 объектов (хосты + сервисы + сетёвка).
• Время реакции на реальный инцидент — в среднем 7 минут.
• Икона Web 2 с Director доступна единой ссылкой для 4 админов страховой.

Стоимость проекта 340 000 руб за 9 рабочих дней, железо NUC — 180 000 руб суммарно.

Обслуживание и оптимизация

Icinga 2 требует немного внимания, но совсем забыть про неё нельзя. Я делаю еженедельные проверки:

• Размер IDO-базы (обычно MariaDB). При 500+ хостах нужна ротация истории через icinga2 feature.
• Logs в /var/log/icinga2/ — ротируются logrotate, но хорошо проверять на ошибки хотя бы раз в месяц.
• Check latency и execution time в /etc/icinga2/zones.conf. Если check_ping выполняется 10 секунд — проблема в сети или плагине.
• TLS сертификаты зон — живут 15 лет по умолчанию, но у нас на практике через 5-7 лет возникают нюансы с обновлением CA.
• Резервные копии /etc/icinga2/ + директора БД — я делаю через rsync в git и pg_dump.

FAQ — частые вопросы по Icinga 2

Чем Icinga 2 отличается от Nagios?

Icinga 2 — форк Nagios с полной переделкой ядра на C++. Современный DSL для конфигурации, встроенный REST API, распределённая архитектура мастер/сателлит/агент, поддержка IPv6 и HA из коробки.

Что такое Icinga Director?

Веб-модуль для icingaweb2, который позволяет управлять конфигурацией через UI вместо правки .conf файлов. Импорт из AD, VMware, PuppetDB, шаблоны хостов и сервисов, проверка изменений перед деплоем.

Нужен ли агент Icinga на серверах?

Агент ставится когда нужно собирать данные изнутри хоста — диски, процессы, сервисы Windows. Для простых проверок (ping, tcp, http, snmp) агент не нужен, мастер опрашивает удалённо.

Как устроена распределённая конфигурация?

Топология Zone: Global (всем), Master (центр управления), Satellite (площадка), Agent (хост). Конфигурация синхронизируется сверху вниз автоматически, проверки выполняются на нужном уровне.

Сколько хостов тянет один мастер?

На виртуалке 4 vCPU / 8 ГБ RAM один мастер спокойно держит 1500-2000 хостов с проверками раз в 5 минут. Для большего — добавляйте сателлиты по площадкам.