🟡 Статус: 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-чеки, штатные шаблоны
Application	1С — очереди, фоновые, лицензии RPHost; SCADA — связь	API, мониторинг логов
Business	«Зарплата начислится?», «Документ выпускается?»	синтетика, e2e-проверки

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

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

• Архитектурно. Модель Purdue и IEC 62443 требуют, чтобы трафик между IT и OT шёл через Industrial DMZ. Прямой коннект из корпоративного 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-проверка до OPC-сервера); даже ICMP является активным зондированием — уточняйте допустимость с командой АСУ ТП. Без агента.

Подробнее — в главе 15 (Антипаттерны).

См. также:

• Purdue Enterprise Reference Architecture — стандартная модель уровней OT/IT
• NIST SP 800-82 Rev. 3 — Guide to OT Security — обязательно к прочтению перед работой с SCADA-сегментом
• CISA Cybersecurity Best Practices for OT
• Приказ ФСТЭК №239 — для понимания, где у вас КИИ

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

Для крупного предприятия (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. Она обеспечивает доступность самого сервиса Zabbix Server: если активная нода упала — standby переключается в active. Это уровень приложения, не базу данных. Patroni решает другую задачу — failover PostgreSQL. Для крупной инсталляции нужны оба механизма: один защищает Zabbix-приложение, другой — базу данных.

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

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

Grafana:

• Используется как слой визуализации и отчётности, а не как основной механизм алертинга. Источником истины по событиям, severity, escalation и acknowledge остаётся Zabbix/ITSM.

• Основной способ подключения — Grafana Zabbix datasource plugin. Он позволяет строить дашборды поверх данных Zabbix: сервисные панели, NOC-экраны, отчёты для тимлидов, CIO и владельцев сервисов. Плагин доступен в каталоге Grafana и сопровождается Grafana Labs. ([Grafana][grafana-zabbix-plugin])

• По умолчанию Grafana обычно работает через Zabbix API. Это нормальный вариант для большинства дашбордов: статусы хостов, проблемы, триггеры, группы, теги, базовые графики, сервисные панели.

• Для тяжёлых исторических графиков возможен режим Direct DB Connection: плагин может читать history/trends напрямую из БД Zabbix и выполнять агрегацию на стороне БД. Это снижает нагрузку на API и ускоряет построение графиков, но требует отдельного read-only доступа к базе и аккуратного контроля запросов. ([Grafana-Zabbix Docs][grafana-zabbix-direct-db])

• Если используется direct DB, Grafana не должна ходить в production-БД Zabbix без ограничений. Правильнее выделить:

• отдельного read-only пользователя;
• read-replica PostgreSQL при высокой нагрузке;
• лимиты на тяжёлые запросы;

• отдельную политику доступа к datasource.

• Grafana не должна становиться вторым центром алертинга поверх Zabbix. Иначе появятся две независимые системы оповещений: Zabbix считает одно, Grafana алертит другое, дежурный получает дубли или противоречивые сигналы. В этой архитектуре правило простое: алертинг и эскалация — в Zabbix/ITSM, визуализация и отчётность — в Grafana.

• Дашборды проектируются не «по метрикам», а по аудиториям (см. глава 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, инженерные станции) — по согласованию с ИБ
• Zabbix proxy — это не просто масштабирование. В заводской архитектуре это прежде всего изоляция сегментов, локальная буферизация данных и устойчивость к временной потере связи с центральным Zabbix Server.
• Постмортем без обратной связи в шаблоны — потеря времени

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