Prometheus + Alertmanager: первый опыт рядом с Zabbix

Prometheus у нас появился не потому что Zabbix плохой. Zabbix хорошо делает то, для чего его настроили: хосты, сервисы, SNMP, стандартные агенты. Проблема появилась когда контейнеров стало достаточно много, чтобы Zabbix начал раздражать. Динамика контейнеров плохо ложится в модель, где каждый объект мониторинга надо зарегистрировать заранее. Prometheus устроен иначе - он сам ходит за метриками по списку таргетов, и добавить новый контейнер означает просто обновить конфиг или настроить service discovery.

Что ставили и зачем

Тестовый стенд собрали на отдельной виртуалке: Prometheus 0.20.0, node_exporter на каждом Docker-хосте, cAdvisor для метрик контейнеров, Alertmanager 0.3. Параллельно Zabbix никуда не делся - он продолжил следить за хостами и сетевым оборудованием. Идея была не заменить, а закрыть конкретный пробел: видимость того, что происходит внутри контейнеров.

Конфиг получился компактным:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['host1:9100', 'host2:9100', 'host3:9100']

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['host1:8080', 'host2:8080', 'host3:8080']

Запустили, зашли в веб-интерфейс, написали первый PromQL-запрос - и он сработал. Это ощущение немного неожиданное после привычной Zabbix-логики с шаблонами, триггерами и LLD.

Как выглядит PromQL рядом с Zabbix

Zabbix хорош когда знаешь что именно хочешь видеть и можешь это сформулировать в терминах его модели данных. PromQL работает иначе - это скорее язык запросов к временным рядам, и выразительность у него совсем другая. Посмотреть CPU по всем контейнерам одного приложения или вычислить процент ошибочных запросов к сервису - на PromQL это несколько строк. В Zabbix то же самое потребует конфигурации.

Минус - порог вхождения. Разница между rate() и irate(), понимание staleness, векторные матчеры - это не очевидно с первого раза. Несколько часов ушло просто на то чтобы написать алертинг-правила без опечаток.

Alertmanager и Slack

Вот тут всё оказалось неожиданно приятным. Настройка Alertmanager свелась к:

global:
  slack_api_url: 'https://hooks.slack.com/services/...'

route:
  receiver: 'slack-ops'

receivers:
  - name: 'slack-ops'
    slack_configs:
      - channel: '#alerts'
        text: '{{ .CommonAnnotations.description }}'

Перезапустили Prometheus с тестовым правилом, которое всегда срабатывает - через минуту в Slack пришло сообщение. Для первого раза это работает быстрее, чем настройка email-уведомлений в Zabbix с нуля на незнакомой инсталляции.

Группировка алертов - отдельный плюс. Если одновременно пять контейнеров начали жрать память, Alertmanager сгруппирует это в одно сообщение а не пять. У Zabbix такого из коробки нет, там без дополнительной работы получаешь шторм нотификаций.

Что насторожило

Первое - хранилище. Prometheus держит данные локально на диске, и по умолчанию retention 15 дней. Это не то чтобы проблема, но надо понимать заранее. Для долгосрочных трендов нужно либо смириться с коротким окном, либо настраивать remote storage - у нас пока не настроено.

Второе - отсутствие push. Некоторые метрики удобнее пушить, а не скрейпить. Для batch-задач и разовых событий Prometheus предлагает Pushgateway, но это уже дополнительный компонент. Zabbix в этом смысле гибче - агент умеет и активно отправлять данные.

Третье - интерфейс. Встроенный UI Prometheus - это инструмент для отладки, не для дашбордов. Для нормальной визуализации нужен Grafana, и это отдельная история. Пока смотрим на это как на следующий шаг.

Где сейчас

Prometheus работает в параллель с Zabbix уже три недели. Контейнерные метрики видны, алерты по памяти и CPU в Slack приходят исправно. Zabbix при этом никуда не делся - хосты, железо, сетевые устройства остаются за ним.

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