Zabbix 4.2 и Prometheus exporter: одна консоль для системных метрик и метрик приложений

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

Контекст такой. На части managed-проектов у нас Zabbix как основная система мониторинга - исторически, по требованиям заказчиков, по зрелости агентской инфраструктуры. Prometheus там тоже живёт местами, но не как основной инструмент. И вот типичная ситуация: на сервере стоит приложение, которое отдаёт метрики через prometheus-экспортер - допустим, node_exporter на 9100 или кастомный экспортер самого приложения. Снять эти метрики в Zabbix раньше означало писать внешний скрипт, оборачивать его в UserParameter, городить парсинг - или всё-таки поднимать Prometheus и тянуть данные оттуда уже в Grafana. Оба варианта имели свою цену.

В 4.2 сделали поддержку Prometheus exporter как нативного типа элемента данных. Zabbix сам ходит за метриками по HTTP, парсит exposition format и складывает нужные метрики как обычные элементы Zabbix - с историей, трендами, триггерами. Всё как обычно, только источник другой.

Что конкретно умеет

Новый тип элемента данных называется Prometheus. В конфигурации указываешь:

• URL экспортера - например http://localhost:9100/metrics.
• Фильтр метрики - PromQL-подобный синтаксис для выборки нужного ряда. Можно указать имя метрики и метки: node_filesystem_avail_bytes{mountpoint="/"}. Не полный PromQL, но для выборки конкретных рядов хватает.
• Функцию агрегации - если метрика возвращает несколько рядов (несколько filesystem с разными mountpoint), можно взять sum, min, max или конкретный ряд по меткам.

Zabbix scrape-ит экспортер по расписанию, фильтрует нужные метрики и пишет их в свою БД. Дальше с ними работаешь как с любыми другими элементами: строишь графики, настраиваешь триггеры, добавляешь в SLA-отчёты.

Важная оговорка: Zabbix тянет метрики через Zabbix Server или Zabbix Proxy, а не через агент. То есть экспортер должен быть доступен с сервера мониторинга по сети, а не только с самого хоста. У нас это нормально - сеть мониторинга открыта как надо. Но если порт экспортера закрыт файрволом «для безопасности», придётся или открывать, или туннелировать через агента - для этого есть обходной путь через UserParameter, но это уже ручная работа.

Как подключали node_exporter

На нескольких хостах у нас уже стояли node_exporter - те самые, которые изначально ставились для экспериментов с Prometheus. Решили их не трогать и подключить прямо к Zabbix.

В Zabbix уже есть встроенный шаблон для node_exporter - Linux by Prom. Он поставляется в 4.2 из коробки и содержит элементы данных с готовыми фильтрами для основных метрик node_exporter: CPU, memory, disk, network, filesystem. Берёшь шаблон, линкуешь к хосту, указываешь в макросах адрес и порт экспортера - и через несколько минут видишь данные.

Что понравилось: шаблон нормально написан. Элементы разнесены по группам приложений, графики приложены, триггеры предусмотрены для базовых ситуаций - высокая загрузка CPU, мало места на диске, сетевые ошибки. Не идеально для каждого конкретного проекта, но как отправная точка - хорошо.

Что настроили поверх: у нас есть хосты, где несколько файловых систем важны по-разному - корень, данные, логи. В шаблоне триггер на filesystem написан как Low Disk Space для любого mountpoint с одним порогом. Мы продублировали элемент данных с фильтром по конкретному mountpoint и сделали отдельный триггер с другим порогом для раздела с данными. Это обычная Zabbix-работа, ничего нового.

Кастомный экспортер приложения

Интереснее стало с кастомным экспортером. На одном проекте приложение отдаёт свои метрики через /metrics - количество обработанных задач, размер очереди, latency по эндпоинтам. Раньше мы смотрели на это только через Grafana, где Prometheus с этого же хоста тянул данные.

Подключили то же самое к Zabbix напрямую. Написали несколько элементов данных с фильтрами по нужным метрикам, добавили триггеры на размер очереди и latency, добавили в дашборд рядом с системными метриками хоста.

Результат: в одном экране Zabbix видно и что с операционкой (CPU, RAM, диск), и что с приложением (очередь растёт или нет, latency держится). Для дежурного это удобнее - не нужно переключаться между Zabbix и Grafana чтобы понять, это хост упирается или приложение. Это не означает что Grafana стала ненужной - там по-прежнему живут детальные дашборды и исторические срезы. Но в оперативной работе иметь всё в одном месте - это реальная ценность.

Что не так гладко

Exposition format - только текст. Zabbix 4.2 понимает текстовый Prometheus exposition format. Protobuf-вариант не поддерживается. Большинство стандартных экспортеров отдают текст по умолчанию, так что на практике это не проблема, но знать стоит.

Нет PromQL-агрегаций. Фильтр в элементе данных - это выборка конкретной метрики с конкретными метками, не произвольный запрос. Посчитать rate() за 5 минут внутри Zabbix нельзя - только взять значение как есть. Для rate-метрик (которые приложение само отдаёт как rate) это не проблема, а для counter-ов нужно либо использовать функции Zabbix (delta, speed per second), либо смириться с тем, что сложные вычисления остаются в Prometheus+Grafana.

Шаблон Linux by Prom и обычный Linux-шаблон. Если хост уже мониторится через Zabbix Agent с классическим шаблоном, добавление Prometheus-шаблона создаёт дублирование части метрик. CPU, memory, filesystem - всё это есть и там, и там. Мы не стали линковать оба шаблона на одни хосты, выбрали один подход на каждый хост в зависимости от того, стоит ли там node_exporter.

Где сейчас

На нескольких проектах подключили node_exporter к Zabbix 4.2. На одном проекте настроили мониторинг кастомного экспортера приложения рядом с системными метриками.

Отдельный Prometheus для этих хостов не нужен - там, где он был ради экспортеров, можно его убрать и упростить инфраструктуру. Там, где Prometheus нужен для других задач (remote_write, AlertManager, сложные PromQL-запросы), он остаётся, и это нормально - инструменты не конкурируют, просто Zabbix теперь умеет читать те же источники данных.