ИТ-отдел узнаёт об отказе SQL Server не из мониторинга серверов, а из звонка бухгалтерии - это реактивная модель. Проактивная - наоборот: видит просадку IOPS и алертит до того, как пользователь заметил. Час простоя биллинга или системы 1С дороже годовой поддержки мониторинга. Дальше - Zabbix, Prometheus или Grafana и почему вопрос «или» здесь некорректный.
Чем эти три инструмента отличаются по сути
Сравнивать Zabbix, Prometheus и Grafana «в лоб» - всё равно что сравнивать СУБД, BI-панель и сервер сбора логов. Это разные слои стека, и путаница между ними приводит к проектам, которые год не выходят из пилота.
Grafana - слой визуализации. Сама метрик не собирает и не хранит. Она забирает данные из источников: Prometheus, Zabbix, VictoriaMetrics, PostgreSQL, Elasticsearch, Loki и рисует дашборды. Без источника данных Grafana бесполезна, это важно понимать на этапе оценки.
Zabbix - комплексная платформа: агенты, сервер, веб-UI, триггеры, шаблоны, своя СУБД для хранения. Поддерживает и pull, и push, умеет SNMP, IPMI, JMX и активные/пассивные проверки. Под классическую инфраструктуру это «всё в одном» из коробки.
Prometheus - pull-модель с собственной TSDB и языком PromQL. Сделан под cloud-native: микросервисы, Kubernetes, динамические инстансы. Поверх Prometheus почти всегда стоит Grafana, рядом - Alertmanager, а долгое хранение выносят в Thanos, Cortex, Grafana Mimir или VictoriaMetrics.
Корректный вопрос - не «zabbix или prometheus», а какая связка работает на конкретном ландшафте. Чаще всего ответ - связка «prometheus и grafana» для контейнеров плюс Zabbix для классической части.
Какой инструмент под какие задачи
Классическая on-premise-инфраструктура
Физические серверы, гипервизоры (VMware, KVM, Proxmox), СУБД (PostgreSQL, MS SQL, кластеры 1С), сетевое оборудование по SNMP, ИБП и IPMI на железе. Инстансы стабильные, IP-адреса не меняются годами, инженер хочет видеть дерево хостов и триггеры без написания кода.
Здесь Zabbix выигрывает по трудозатратам. Готовые шаблоны для большинства вендоров, агент с автодискавери дисков и сетевых интерфейсов, SNMP и IPMI из коробки, веб-UI, в котором админ настраивает триггеры мышью. Алерты собираются в эскалации, пользователи разводятся по группам и правам.
Практический вывод: если ландшафт классический и в штате нет инженера, который пишет на PromQL и поддерживает экспортёры, то Zabbix дешевле по человеко-часам и быстрее выходит в продакшн. Сценарий «zabbix или prometheus» здесь решается в пользу Zabbix.
Контейнерные и микросервисные среды: Kubernetes, Docker
В Kubernetes поды появляются и исчезают по автоскейлу, IP-адреса перевыпускаются, сервисы переезжают между узлами. Классическая модель «один хост - один агент - статичный список метрик» в этой среде ломается на первой неделе.
Prometheus сделан под эту картину. Service discovery подключается напрямую к Kubernetes API и сам находит новые поды. Метрики снимают экспортёры: node_exporter с узлов, kube-state-metrics с control plane, cAdvisor с контейнеров, плюс инструментированные приложения отдают /metrics нативно. PromQL даёт агрегации по лейблам - namespace, deployment, pod.
Поверх ставят Grafana с готовыми дашбордами для Kubernetes (их сотни в публичном каталоге), Alertmanager рассылает уведомления, а сырые метрики со временем уезжают в Mimir или VictoriaMetrics. Связка «prometheus и grafana» - отраслевой стандарт для контейнерных платформ, и переизобретать её Zabbix-ом дороже, чем взять готовое.
На смешанной инфраструктуре оба стека живут параллельно: Zabbix покрывает железо, гипервизоры и СУБД, Prometheus с Grafana - контейнерную платформу и приложения. Это не дублирование, а разграничение зон ответственности и так выглядит мониторинг серверов в большинстве зрелых ИТ-отделов.
Архитектура и требования к серверу мониторинга
От распределения задач переходим к железу. Сервер мониторинга - не «маленькая ВМ на 4 ГБ», как принято думать на старте. Это сервис с тремя ресурсоёмкими компонентами, каждый из которых упирается в свой ресурс.
Сбор метрик нагружает CPU и сеть: тысячи опросов в минуту, обработка ответов, парсинг. Хранение TSDB упирается в диск и IOPS - сырой ряд за месяц по 1000 хостов это сотни гигабайт и постоянная случайная запись. Отрисовка дашбордов и обработка алертов снова требуют CPU и RAM, особенно когда PromQL-запрос разворачивает агрегацию по часу.
Под 500–1000 хостов сервер сбора собирают на NVMe, выделяют 16–32 ГБ RAM и считают объём под TSDB. Ориентир по дискам: Prometheus на 1000 хостов с интервалом опроса 15 секунд складывает порядка 3–4 ГБ сырых метрик в сутки, то есть 50–120 ГБ под ретеншн 15–30 дней. Zabbix с типовыми шаблонами на ту же тысячу хостов даёт 150–350 ГБ history за месяц - в основном за счёт более широкого набора собираемых элементов и накладных расходов СУБД. Сверху на агрегации по часу и дню под хранение год+ закладывают ещё 30–50% к сырому объёму. На горячем NVMe держат сырые ряды и индексы, долгое хранение под отчёты выносят в Mimir, Thanos или VictoriaMetrics с дисками подешевле. Канал до агентов выделяют отдельно с QoS, чтобы пик опросов не конкурировал с продуктовым трафиком.
Под высокую нагрузку имеет смысл подбирать оборудование для мониторинга ЦОД целенаправленно - конфигурации с большим количеством шпинделей и NVMe под TSDB. Алертинг - Alertmanager или Zabbix Server, выносят на отдельный узел, чтобы при пике метрик не задержались уведомления.
Главное: сама система мониторинга инфраструктуры - критичный сервис. Резервирование, RAID, бэкапы конфигурации, и обязательно - мониторинг самого мониторинга. Молчащий Prometheus или Zabbix не значит «всё хорошо», это значит «мы ничего не знаем».
Стоимость и трудоёмкость внедрения
Open-source не значит бесплатно
Когда инструменты понятны и архитектура прикинута, начинается разговор про деньги. Здесь у руководителей ИТ-отделов возникает иллюзия: и Zabbix, и Prometheus, и Grafana распространяются по открытым лицензиям, значит, проект бесплатный. На практике лицензия 0 не равна нулевой стоимости.
Платят человеко-часами - внутренними или подрядными. Базовый Zabbix на 100–200 хостов с типовыми шаблонами и парой групп пользователей разворачивается за 2–4 недели работы инженера. Production-ready связка Prometheus и Grafana с Alertmanager, экспортёрами, дашбордами под Kubernetes и понятной ротацией данных - это 1–2 месяца, и команда уровня middle, а не стажёр.
Дальше - эксплуатация. Кто-то пишет новые правила алертов, чистит старые дашборды, обновляет версии, разбирает ложные срабатывания. Без выделенного владельца через год получится «пишет всем подряд в чат, никто не реагирует». Это OpEx, и его считают честно.
Коммерческая поддержка снимает часть рисков. Zabbix LLC даёт SLA на ответ и помощь по архитектуре. Grafana Cloud - managed TSDB и Grafana без своей инфраструктуры. Российские интеграторы предлагают внедрение и сопровождение с договором - это важно для регулируемых отраслей, где нужен поставщик с ответственностью на бумаге.
Вывод по бюджету: open-source убирает лицензионный CapEx, но не убирает OpEx на людей. Если в команде нет инженера под систему мониторинга инфраструктуры, считать надо стоимость найма или подряда, а не строчку «лицензия - 0 рублей».
Типичные ошибки внедрения
Перейдём от расчётов к практике. Пять ошибок встречаются почти в каждом проекте мониторинга, и каждая стоит реального простоя или выгорания дежурной смены.
- Алерты на всё подряд. Команда включает уведомления по каждой метрике, ночная смена за неделю привыкает игнорировать чат - это alert fatigue. Когда приходит настоящий инцидент, его пропускают.
- Мониторинг без RTO и RPO. Метрики собирают, дашборды рисуют, но критерии «что считать сбоем» не зафиксированы. Инженер видит красную плашку и не понимает, нужно ли будить руководителя.
- Нет runbook к алерту. В три ночи приходит «CPU 95% на узле БД» и инженер сидит и думает, что с этим делать. Каждый алерт должен ссылаться на короткую инструкцию: что проверить, кого эскалировать.
- Grafana без правил очистки. За год набирается несколько сотен дашбордов, половина - заброшенные эксперименты. Найти нужный становится дольше, чем зайти на сервер по SSH.
- Prometheus на legacy без экспортёров. Команда пытается мониторить старую СУБД или промышленный контроллер, экспортёра нет, начинают писать свой, проект растягивается на квартал. Для такого ландшафта Zabbix-агент или SNMP закроют задачу за день.
Сквозной вывод: технология не заменяет процесс. Без владельца, регламента и runbook любая система мониторинга инфраструктуры через полгода превращается в шум, на который никто не смотрит.
С чего начать выбор
Чтобы не выбирать инструмент по моде, начинают не с продукта, а с трёх вопросов о себе.
- Какой у вас ИТ-ландшафт? Классический (физические серверы, гипервизоры, SNMP, СУБД, кластеры 1С) - Zabbix закроет задачу быстрее и без PromQL в штате. Контейнерный (Kubernetes, динамические инстансы, микросервисы) - связка Prometheus и Grafana. Смешанный - оба стека параллельно, каждый на своей зоне.
- Есть ли в команде инженер, который читает PromQL и поддерживает экспортёры? Да - Prometheus с Grafana работает в полную силу. Нет - либо Zabbix как менее требовательный по компетенциям, либо Prometheus, но с подрядной поддержкой. Без одного из этих вариантов проект на втором месяце буксует на ручных задачах.
- Нужна ли коммерческая поддержка с договором? Регулируемая отрасль (КИИ, банковский сектор, госзаказ), где «опенсорс на честном слове» не пройдёт аудит - Zabbix LLC, Grafana Cloud, российский интегратор с SLA на бумаге. Обычная отрасль - поддержку считают опционально, по бюджету.
На пересечении ответов остаётся один из трёх сценариев: Zabbix на классике, Prometheus с Grafana на контейнерах или обе связки параллельно. Перед запуском полезно понять, что именно мониторить и где сегодня слепые зоны - это закрывается через аудит ИТ-инфраструктуры.
