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

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

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

Zabbix, на мой взгляд, прекрасно подходит для сбора метрик и построения красивых графиков, тут вопросов нет. А Prometheus? Это вообще идеальный вариант для облачной инфраструктуры, особенно с Kubernetes. Но если вам нужна не просто информация, а настоящая надёжность, чёткость и полная ясность, когда хост действительно работает, а когда сломан, когда сервис OK, а когда уже CRITICAL – тогда я однозначно выбираю Icinga. Это мир, где правят стейт-машины, где эскалации максимально эффективны, а SLA-отчёты всегда точны.

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

• Для кого Icinga подходит идеально? Для распределённых инфраструктур, где есть несколько центров обработки данных (ЦОД) или множество филиалов.
• Для банков и госсектора, например, особенно важны две вещи: строгая «нагиосоподобная» парадигма и полный audit trail. Мы это прекрасно понимаем и учитываем в работе.
• Что делать, если у вас не однородная система? Мы регулярно сталкиваемся со смешанными IT-окружениями: здесь 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"
}

Достаточно перезапустить icinga2 на мастере — и вуаля! Сателлит тут же появляется в веб-интерфейсе. Всё, можно смело назначать на него проверки.

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

Если честно, настроить Icinga без Director можно только через .conf файлы. Да, это очень мощно, никто не спорит. Но для по-настоящему большой команды такой подход становится просто жутко неудобным. Именно Director даёт нам классный веб-интерфейс поверх тех же самых объектов, добавляет возможности импорта данных из внешних источников и, что самое важное, позволяет проверить конфигурацию ещё до её деплоя.

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. В итоге что получили? Все сервера оказались объединены в одной консоли, создав 14 изолированных зон. Но самое классное знаете что? При обрыве связи с филиалом локальный сателлит не останавливается: он продолжает исправно выполнять проверки, сохраняет все данные, а синхронизация происходит мгновенно, сразу же после восстановления линка.

• Наши клиенты видят реальные результаты. Например, количество алертов с ложной срабатываемостью сократилось драматически: с двадцати штук в день до одного-двух. Представьте, сколько времени это экономит?
• У нас в работе система, которая мониторит 480 различных объектов. И это не просто абстрактные цифры: это и хосты, и сервисы, и всё ваше сетевое оборудование под нашим надзором.
• Когда происходит реальный инцидент, время на вес золота, верно? Мы гордимся тем, что среднее время реакции на подобные ситуации у наших клиентов — всего 7 минут. Просто подумайте, сколько это значит для бизнеса.
• Как это работает на практике? Вот свежий пример: для четырёх администраторов крупной страховой компании вся «Икона» мониторинга — то есть Icinga Web 2 с Director — доступна по одной-единственной ссылке. Удобно, быстро, без лишних телодвижений.

По финансам: весь проект обошёлся нам в 340 000 рублей, и мы уложились всего в 9 рабочих дней! Что касается железа NUC, оно добавило к общей стоимости ещё 180 000 рублей суммарно.

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

Конечно, Icinga 2 требует к себе немного внимания — это не система по принципу «поставил и забыл». Полностью забывать про неё ни в коем случае нельзя! Поэтому я лично всегда делаю еженедельные проверки. Вот что входит в мой чек-лист:

• Размер IDO-базы (обычно MariaDB). При 500+ хостах нужна ротация истории через icinga2 feature.
• Logs в /var/log/icinga2/ — ротируются logrotate, но хорошо проверять на ошибки хотя бы раз в месяц.
• Мы всегда смотрим на детали. Например, в файле /etc/icinga2/zones.conf можно найти важные параметры: check latency и execution time. Если тот же check_ping вдруг выполняется целых десять секунд — это сигнал. Сразу понятно: что-то не так либо с сетью, либо с самим плагином. Ищем причину и чиним.
• Да, TLS-сертификаты для зон по умолчанию «живут» аж пятнадцать лет. Красиво? Звучит отлично. Но вот на нашей практике мы видим, что уже через пять-семь лет регулярно возникают специфические нюансы с обновлением центра сертификации (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 минут. Для большего — добавляйте сателлиты по площадкам.