Мониторинг IT-инфраструктуры: SCOM, Zabbix и SNMP-решения

Мониторинг IT-инфраструктуры — это непрерывный сбор, анализ и визуализация данных о состоянии серверов, сетевого оборудования, систем хранения данных (СХД), центров обработки данных (ЦОД) и приложений. Его цель — обнаруживать сбои и деградацию производительности до того, как они скажутся на бизнесе. Правильно выстроенный мониторинг сокращает MTTR (среднее время восстановления), снижает риск простоев и помогает планировать ресурсы.

Типичный периметр мониторинга включает серверы, сети и коммутаторы, ЦОД и гипервизоры, СХД и SAN, базы данных, приложения (APM) и облачные ресурсы. Для каждого слоя собираются свои метрики: для серверов — CPU, RAM, disk I/O; для сети — latency, packet loss, bandwidth; для СХД — IOPS, throughput, свободное место.

Мониторинг — это сбор заранее определённых метрик и срабатывание алертов при пересечении порогов. Observability — более широкая концепция: она предполагает, что состояние системы можно понять по её «выходным сигналам» — метрикам (metrics), логам (logs) и трассировкам (traces), даже если вы заранее не знали, что именно искать. Инструменты вроде Prometheus + Grafana или OpenTelemetry закрывают оба подхода.

Zabbix — монолитная платформа «всё-в-одном»: агент, сервер, база данных и веб-интерфейс идут в комплекте. Хорошо подходит для мониторинга классической on-premise инфраструктуры с минимальным порогом входа.
Prometheus + Grafana — стек pull-модели, ориентированный на динамичные облачные среды и Kubernetes. Требует больше настройки, зато даёт гибкость запросов через PromQL и отлично масштабируется. Если у вас микросервисы или контейнеры — выбор очевиден.

SCOM — корпоративная платформа Microsoft для мониторинга Windows-инфраструктуры: серверов, AD, SQL Server, Exchange, IIS и других компонентов экосистемы. Её ключевая ценность — Management Packs: готовые пакеты правил, метрик и алертов для конкретных продуктов Microsoft. SCOM хорошо интегрируется с Azure, SCOM MI и ITSM-системами (ServiceNow, System Center). Оправдан, если в организации большой парк Windows-серверов и развитая экосистема Microsoft.

SNMP (Simple Network Management Protocol) — стандартный протокол опроса сетевых устройств: маршрутизаторов, коммутаторов, принтеров, ИБП, промышленного оборудования. Устройство возвращает значения из своей MIB-базы (Management Information Base). SNMP v1/v2c достаточно для базового мониторинга сети; v3 добавляет шифрование и аутентификацию. Для серверов и приложений SNMP обычно дополняют агентами (Zabbix Agent, NRPE, WMI), которые дают более детальные метрики.

Grafana — платформа визуализации и аналитики, которая сама по себе не хранит метрики. Она подключается к источникам данных: Prometheus, InfluxDB, Elasticsearch, Loki, Zabbix, Datadog и многим другим через плагины. В Grafana создаются дашборды с графиками, таблицами, тепловыми картами и алертами. Часто используется как единая «стеклянная панель» поверх нескольких систем мониторинга, что позволяет видеть инфраструктуру целиком на одном экране.

Несколько принципов для борьбы с «alert fatigue»:
Используйте скользящие окна вместо мгновенных порогов — например, CPU > 90% на протяжении 5 минут, а не разовый всплеск.
Разделяйте алерты по приоритету: critical (немедленное действие), warning (наблюдение), info (информация).
Добавляйте контекст в уведомление: хост, метрика, текущее значение, ссылка на дашборд и runbook.
Регулярно ревьюйте алерты — удаляйте те, по которым никто не предпринимает действий.

Типовая архитектура — иерархическая. В каждом удалённом офисе или ЦОД устанавливается локальный прокси или агрегатор (Zabbix Proxy, Prometheus remote_write, Victoria Metrics agent), который собирает данные и передаёт их в центральный сервер мониторинга. Это снижает нагрузку на WAN-каналы и обеспечивает локальную работоспособность сбора данных даже при потере связи с центром

Для мониторинга СХД используют несколько подходов одновременно: опрос по SNMP для получения базового статуса устройства, vendor API (REST или proprietary) для детальных метрик конкретного массива (EMC, NetApp, HPE 3PAR, Pure Storage), а также агенты или exporters для Prometheus. Ключевые метрики: IOPS, throughput (MB/s), latency (мс на операцию), утилизация томов, статус RAID-групп и состояние дисков (S.M.A.R.T.).

Физические параметры ЦОД — температура, влажность, ИБП, ПДУ (Power Distribution Unit), системы кондиционирования — обычно мониторятся отдельно через DCIM-системы (Data Center Infrastructure Management) или SNMP-опрос соответствующего оборудования. Данные можно интегрировать в единый стек (например, через Zabbix или Grafana), чтобы коррелировать физические события с деградацией производительности серверов.

Большинство зрелых платформ (Zabbix, SCOM, Nagios, Datadog) поддерживают webhook-уведомления и прямые интеграции с ServiceNow, Jira Service Management, Freshservice. При срабатывании критичного алерта автоматически создаётся инцидент с заполненными полями (хост, описание, приоритет, ссылка на дашборд). Это ускоряет эскалацию и сохраняет контекст для постмортема.

Конфигурации мониторинга хранятся в Git и применяются через CI/CD — это называют «Monitoring as Code». Prometheus правила алертов описываются в YAML, Grafana-дашборды экспортируются в JSON и версионируются, Zabbix шаблоны экспортируются через API. Инструменты: Terraform (для облачных мониторинговых ресурсов), Ansible (для развёртывания агентов), Jsonnet/Grafonnet (для генерации Grafana-дашбордов программно).

Зависит от целей. Для оперативного реагирования достаточно 15–30 дней с высоким разрешением (1–10 сек). Для анализа трендов и планирования мощностей — 12–18 месяцев с агрегацией (1–5 мин). Prometheus хранит данные локально с ограниченным retention; для долгосрочного хранения используют удалённые хранилища: Thanos, VictoriaMetrics, Cortex. Zabbix поддерживает настройку housekeeping прямо в интерфейсе.