Prometheus или Zabbix: что ставить для мониторинга

Сравнения этих двух обычно выглядят как таблица на сорок строк, где у обоих почти везде галочки. Таблица не врёт и не помогает: она сравнивает возможности, а разница лежит уровнем ниже — в том, откуда система вообще узнаёт, за чем ей следить.

Две разные картины мира

Zabbix думает узлами. Есть хост, у хоста шаблон, в шаблоне элементы данных и триггеры. Инвентарь заводится — руками или обнаружением — и живёт как дерево. Вопрос, на который система отвечает хорошо: «что происходит вот с этой машиной».

Prometheus думает временными рядами. Единица — не хост, а метрика с набором меток: http_requests_total{method="POST", code="500", service="orders"}. Сервер сам ходит по целям и снимает показания с их адреса /metrics. Цели он берёт из обнаружения — из оркестратора, из списка, из служебного каталога. Вопрос, на который он отвечает хорошо: «как ведёт себя вот этот срез по всем экземплярам сразу».

Отсюда всё остальное. Метки — не украшение, а способ задавать вопросы: в Zabbix «доля пятисотых по сервису заказов за пять минут» собирается через отдельно заведённые элементы, в Prometheus это одна строка на языке запросов.

Где Zabbix сильнее, и это не ностальгия

Железо и сеть. SNMP, IPMI, коммутаторы, источники бесперебойного питания, температура в стойке. Prometheus сюда дотягивается через переходники, и это всегда лишний слой. Zabbix умеет это из коробки и умеет давно.

Инвентарь как ценность сама по себе. Список хостов с их ролями, серийниками и ответственными — рабочий артефакт, а не побочный продукт. В Prometheus такого понятия нет вовсе.

Готовое дежурство. Эскалации, расписания, подтверждение реакции — встроены. У Prometheus за это отвечает отдельный Alertmanager, и маршрутизация описывается конфигурацией.

Агент без доработки приложения. Zabbix снимает показания с машины, ничего не требуя от кода. Prometheus требует, чтобы приложение отдавало /metrics, — то есть чтобы кто-то его научил.

Где Prometheus сильнее

Цели, которых не существовало минуту назад. Контейнер поднялся, обнаружение его нашло, метрики пошли. Заводить его в инвентаре никто не будет — он проживёт двадцать минут. Для Zabbix это чужой сценарий: дерево хостов не рассчитано на то, что листья появляются и исчезают сами.

Вопросы по срезам. «Девяносто девятый перцентиль по всем экземплярам сервиса, кроме канареечного» — обычный запрос. Правда, перцентиль здесь считается по гистограмме, а не по сырым замерам, и у этого есть своя цена в точности.

Метрики приложения, а не машины. Длина очереди, возраст самого старого необработанного сообщения, доля ответов из кеша. Это то, что знает только код, и Prometheus заточен под такие показатели.

Про что молчат обе стороны

Кардинальность убивает Prometheus. Метка с неограниченным набором значений — идентификатор пользователя, номер заказа, путь запроса с параметрами — порождает отдельный временной ряд на каждое значение. Сервер съедает память и падает. Это не настройка, а свойство модели: метки годятся для измерений с коротким списком значений, и ни для чего больше.

Prometheus не хранит долго. Его хранилище локальное и рассчитано на недели. Годовые графики живут в другом месте, куда данные уезжают отдельным каналом. Планировать это надо сразу, а не через год.

Ни то, ни другое не заменяет журналы и трассировку. Метрика говорит, что доля ошибок выросла. Она не говорит, что именно сломалось — про разделение труда между тремя источниками есть отдельный разбор.

История Zabbix лежит в реляционной базе. Это ровно та часть, которая первой упирается в объём при росте числа элементов, и обслуживать её придётся как обычную большую базу.

Кто за это отвечает

Разница, которую видно только через полгода эксплуатации.

Zabbix ставит и ведёт администратор. Разработчик к нему не подходит: шаблоны, триггеры и элементы данных живут в интерфейсе системы, а не в репозитории приложения.

Prometheus этого не позволяет. Метрики приложения пишет тот, кто пишет приложение: счётчик и гистограмма объявляются в коде, рядом с логикой, которую они измеряют. Мониторинг перестаёт быть чужой зоной и становится частью задачи — вместе с обязанностью не наплодить меток.

Отсюда практический вывод: если разработчики не готовы трогать код ради метрик, Prometheus даст вам ровно то же, что Zabbix, — загрузку процессора и память, — но за большие деньги в эксплуатации. Его преимущество целиком в тех показателях, которые знает только код.

Признак, по которому я выбираю

Один вопрос: меняется ли перечень наблюдаемого без вашего участия?

Парк машин известен, растёт медленно, в нём есть железо и сеть — Zabbix. Вы получите инвентарь, дежурство и опрос по SNMP, не написав ни строки.

Сервисы приезжают и уезжают сами, число экземпляров плавает, а интересные показатели живут внутри приложения — Prometheus. Здесь Zabbix будет постоянно отставать от реальности, и отставание придётся закрывать скриптами.

Смешанный случай — когда есть и стойка, и оркестратор — встречается чаще любого чистого, и в нём обе системы уживаются: Zabbix на железе, Prometheus на сервисах. Это не поражение архитектуры. Одна система на всё здесь дороже двух по назначению.

Условие, при котором я неправ

Если у вас три сервера и один сервис, не ставьте ни того, ни другого сразу. Начните с того, чтобы каждое правило называло действие — алерт без действия вреднее его отсутствия, и это решается не выбором системы, а дисциплиной. Инструмент, поднятый раньше, чем появились вопросы, отвечает на чужие.