Мониторинг серверов: Zabbix, Prometheus или Grafana — что выбрать

ИТ-отдел узнаёт об отказе 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 для классической части.

Физические серверы, гипервизоры (VMware, KVM, Proxmox), СУБД (PostgreSQL, MS SQL, кластеры 1С), сетевое оборудование по SNMP, ИБП и IPMI на железе. Инстансы стабильные, IP-адреса не меняются годами, инженер хочет видеть дерево хостов и триггеры без написания кода.

Здесь Zabbix выигрывает по трудозатратам. Готовые шаблоны для большинства вендоров, агент с автодискавери дисков и сетевых интерфейсов, SNMP и IPMI из коробки, веб-UI, в котором админ настраивает триггеры мышью. Алерты собираются в эскалации, пользователи разводятся по группам и правам.

Практический вывод: если ландшафт классический и в штате нет инженера, который пишет на PromQL и поддерживает экспортёры, то Zabbix дешевле по человеко-часам и быстрее выходит в продакшн. Сценарий «zabbix или prometheus» здесь решается в пользу Zabbix.

В 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 не значит «всё хорошо», это значит «мы ничего не знаем».

Когда инструменты понятны и архитектура прикинута, начинается разговор про деньги. Здесь у руководителей ИТ-отделов возникает иллюзия: и 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 рублей».

Перейдём от расчётов к практике. Пять ошибок встречаются почти в каждом проекте мониторинга, и каждая стоит реального простоя или выгорания дежурной смены.

Сквозной вывод: технология не заменяет процесс. Без владельца, регламента и runbook любая система мониторинга инфраструктуры через полгода превращается в шум, на который никто не смотрит.

Чтобы не выбирать инструмент по моде, начинают не с продукта, а с трёх вопросов о себе.

На пересечении ответов остаётся один из трёх сценариев: Zabbix на классике, Prometheus с Grafana на контейнерах или обе связки параллельно. Перед запуском полезно понять, что именно мониторить и где сегодня слепые зоны - это закрывается через аудит ИТ-инфраструктуры.