Перейти к содержанию

🟡 Статус: Design draft · v0.1

Подход правильный, но конкретный код, конфиги или пороги требуют валидации в вашем окружении.

Мост между методикой первой части и реальной инсталляцией. Архитектура развёртывания — proxy, DMZ, OT и КИИ как ограничение. План внедрения на 90 дней — для нового запуска или входа в чужой Zabbix. Минимальный GitOps — чтобы изменения в UI не растворялись.

06. Архитектура и развёртывание

Архитектура мониторинга — это не «куда поставить Zabbix Server». Это полная цепочка: от того, как метрика собирается, до того, как постмортем меняет шаблоны. Каждое звено должно быть осмыслено.

Эта глава — про:

  • Конвейер мониторинга и его слои
  • Архитектуру развёртывания Zabbix (Server + Proxy + БД)
  • IT/OT разделение (Purdue, 187-ФЗ)
  • Поток данных от метрики до постмортема

Конвейер мониторинга

Мониторинг — это не «поставили Zabbix», это функция эксплуатации. Конвейер:

Сбор (агенты / SNMP / WMI / API)
   → Хранение (Zabbix DB + долгий retention в Postgres/TSDB)
   → Корреляция (триггеры, dependencies, теги)
   → Визуализация (Grafana поверх Zabbix datasource)
   → Алертинг (escalation в каналы + ITSM-тикет)
   → Реагирование (runbook → дежурный)
   → Постмортем → обратно в шаблоны

Если какое-то звено отсутствует или сломано — у вас не мониторинг, а декорация. Типичные пробои:

  • Нет корреляции → 50 алертов на один инцидент
  • Нет runbook → дежурный гуглит в 3 ночи
  • Нет обратной связи от постмортема → одни и те же грабли каждый месяц

Слои мониторинга

Снизу вверх (повторение из главы 1, но в контексте архитектуры):

Слой Что Чем
Hardware iLO/iDRAC, ИБП, температура, RAID SNMP, IPMI
Network Cisco/Eltex/UserGate — порты, CPU, BGP, тоннели SNMP, SNMP-traps
OS Win/Linux — CPU, RAM, диски, сервисы Zabbix-agent (active)
СУБД / Middleware MSSQL, PostgreSQL; Exchange DAG, IIS, веб-публикации 1С SQL-чеки, native templates
Application 1С — очереди, фоновые, лицензии RPHost; SCADA — связь API, log-monitoring
Business «Зарплата начислится?», «Документ выпускается?» синтетика, e2e-чеки

IT vs OT — разделение

Критично для производственного предприятия. SCADA (MasterScada4D, WinCC, и пр.) — это OT-сегмент. Граница IT/OT — не просто техническое разделение, а архитектурное, нормативное и операционное требование:

  • Архитектурно. Модель Purdue и IEC 62443 требуют, чтобы трафик между IT и OT шёл через Industrial DMZ. Прямой коннект из IT-Zabbix в L0–L2 — это и есть то неконтролируемое прохождение между уровнями, от которого модель защищает.
  • Нормативно. Zabbix может быть частью контура мониторинга ЗОКИИ, но соответствие мерам приказа ФСТЭК №239 обеспечивается архитектурой, процессами, СЗИ и сертифицированными средствами там, где это требуется — open-source Zabbix сам по себе этого не закрывает. Уточняйте у ИБ/владельца ЗОКИИ. Существуют сертифицированные сборки на основе Zabbix (например, UDV ITM), которые могут закрывать отдельные требования.
  • Операционно. Для пассивного анализа OT-трафика есть специализированные системы (PT ISIM, KICS for Networks, DATAPK), которые слушают копию трафика через SPAN-порт и понимают Modbus, OPC, S7 на уровне DPI. Zabbix этого не умеет.

Где Zabbix уместен в OT: верхние уровни (Historians, инженерные станции, серверы SCADA на Windows) — по согласованию с ИБ, с отдельным Proxy в DMZ и белым списком метрик. Контроллеры и АРМ L0–L2 — только согласованные read-only проверки после оценки риска с АСУ ТП/ИБ (ICMP, SNMP read-only, TCP-check до OPC-сервера); даже ICMP является активным зондированием — уточняйте допустимость с командой АСУ ТП. Без агента.

Подробнее — в главе 15 (Anti-patterns).

См. также:

Архитектура развёртывания

Для крупного предприятия (1–5К хостов, несколько площадок):

                    +--------------+
                    | Zabbix Server| -- Postgres (Patroni HA)
                    |   (frontend) | -- Grafana (read-only viz)
                    +------+-------+
                           |
           +---------------+---------------+
           |               |               |
       +---+----+      +---+----+      +---+------+
       | Proxy  |      | Proxy  |      |  Proxy   |
       | Корп.  |      | SCADA  |      |  Дальн.  |
       | сегм.  |      | DMZ    |      | площадка |
       +--------+      +--------+      +----------+

Зачем прокси:

  • Разгрузка сервера (агенты ходят к прокси, не к серверу)
  • Изоляция сегментов (SCADA-прокси в DMZ, без доступа в OT внутрь)
  • Переживание обрыва канала (буферизация локально)

На каждой площадке / каждом изолированном сегменте — свой прокси. В базовой схеме агент закреплён за одним proxy; отказоустойчивость proxy проектируется отдельно (резервный proxy, failover через API/autoregistration — в зависимости от требований к доступности).

Zabbix Server HA:

⚠ Версия Zabbix: native HA для Zabbix Server (active/standby) доступен начиная с Zabbix 6.0 LTS. Он защищает процесс сервера, а не БД — это разные уровни. В схеме с Patroni: Patroni защищает PostgreSQL, Zabbix Server HA защищает server process. Для крупных инфраструктур имеет смысл совмещать оба.

Postgres (reference design при наличии компетенций):

  • HA через Patroni + etcd/consul — рекомендуемый подход для production, но не единственный; выбирайте по зрелости команды
  • WAL-G для backup в S3-совместимое хранилище
  • Retention strategy обязательна с первого дня; конкретный способ (TimescaleDB, нативное партиционирование или усиленный housekeeping) выбирается после sizing по NVPS и объёму истории
  • Отдельный read-replica для Grafana (чтобы дашборды не клали БД) — при использовании direct DB; Grafana Zabbix datasource plugin чаще ходит через Zabbix API

Grafana:

  • Только для визуализации, не для алертинга
  • Использует Zabbix как datasource (Grafana Zabbix datasource plugin, поддерживаемый сообществом совместно с Grafana Labs)
  • Дашборды — по сервисам и аудиториям (см. глава 3)

Поток данных от метрики до постмортема

7 слоёв сверху вниз:

ИСТОЧНИКИ:        Hardware · Network · OS · Apps · Synthetic · OT (пассив!) · Logs
                                          ↓
СБОР:             Zabbix Proxy: Corp · OT DMZ · Remote Sites
                                          ↓
ЯДРО:             Zabbix Server + PostgreSQL (Patroni, WAL-G, partitioned)
                                          ↓
ОБРАБОТКА:        Trigger Evaluation → Event Correlation → Dependency Suppression → Tag Routing
                                          ↓
КАНАЛЫ:           NOC TV · Grafana · Telegram · Email · SMS (только P1) · Webhook · Auto Reports → CIO
                                          ↓
РЕАКЦИЯ:          ServiceDesk · Runbooks · Список дежурных · Эскалация L1→L2→CIO · Audit Git
                                          ↓
ИНЦИДЕНТ:         Acknowledge → Диагностика → Resolve → Постмортем
                                          ↓
ОБРАТНАЯ СВЯЗЬ:   Постмортем → обновление шаблонов / порогов / runbook → обратно в Сбор

Это и есть полный цикл. В реальных инсталляциях обычно:

  • Сбор, хранение, ядро — присутствуют
  • Корреляция и dependencies — рудиментарно или отсутствуют
  • Каналы — частично (часто только Email)
  • Реакция — без runbook
  • Постмортем — раз в полгода, без структуры
  • Обратная связь — никакой

Зрелый мониторинг — это замкнутый цикл. Не «поставили и забыли».

Резюме

  • Мониторинг — это конвейер, а не точка. Считайте все 7 звеньев
  • IT и OT разделяются — Zabbix-агент в L0–L2 OT не ставится; верхние уровни (Historians, инженерные станции) — по согласованию с ИБ
  • Прокси нужны не для масштаба, а для изоляции и переживания обрыва
  • Постмортем без обратной связи в шаблоны — потеря времени

См. также: Глава 7 — Roadmap внедрения.