Как проверить алерт до аварии: тесты правил с promtool

Порог в правиле выглядит правильно, но поведение во времени трудно проверить чтением YAML. Когда начинается pending? Что произойдёт после короткого восстановления? Не затронула ли правка labels ожидаемое уведомление? Для этих вопросов удобен небольшой воспроизводимый набор samples, который вычисляет сам Prometheus через promtool.

Возьмём доступность одного target. Он работает на нулевой минуте, затем четыре минуты не опрашивается успешно и на пятой восстанавливается. Правило должно перейти в firing после двух минут непрерывно наблюдаемого нулевого up. Все интервалы в примере равны минуте, чтобы границы легко проверялись.

Сохраним правило отдельно

Файл rules.yml содержит обычную группу:

groups:
  - name: availability
    rules:
      - alert: ApiDown
        expr: up{job="api"} == 0
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "API target недоступен"

Само сравнение возвращает подходящую серию со значением 0. Для активности алерта важно её присутствие в результирующем векторе. Модификатор bool здесь не нужен. Теперь создадим рядом tests.yml:

rule_files:
  - rules.yml
evaluation_interval: 1m
tests:
  - interval: 1m
    input_series:
      - series: 'up{job="api",instance="api:9100"}'
        values: '1 0 0 0 0 1'
    alert_rule_test:
      - eval_time: 2m
        alertname: ApiDown
        exp_alerts: []
      - eval_time: 3m
        alertname: ApiDown
        exp_alerts:
          - exp_labels:
              job: api
              instance: api:9100
              severity: warning
            exp_annotations:
              summary: "API target недоступен"
      - eval_time: 5m
        alertname: ApiDown
        exp_alerts: []

Разберём ожидаемое время

Первый sample относится к 0m. На 1m up впервые равен нулю, и начинается pending. На 2m прошла только одна минута ожидания: firing-алертов нет. На 3m условие выдержано две минуты, поэтому ожидается один алерт с заданными labels и annotation. На 5m up снова равен единице, и выражение больше не возвращает эту серию.

Тест на 2m особенно полезен: если случайно убрать for, он завершится ошибкой, хотя проверка только на 3m могла бы остаться зелёной. Проверка 5m подтверждает завершение при восстановлении. exp_alerts описывает firing-алерты; пустой список не доказывает отсутствие pending.

Запустим проверку в проекте

promtool check rules rules.yml
promtool test rules tests.yml

Запускайте команды из каталога с обоими файлами. Первая проверяет правила, вторая вычисляет заданные временные случаи и сравнивает ожидаемые результаты. Успех теста означает совпадение этой модели с ожиданием. Версию promtool удобно согласовать с используемым Prometheus, чтобы изменения языка и возможностей не расходились между CI и сервером.

В expected labels перечислены labels результирующего алерта без метки alertname: имя алерта уже задано в alertname тестового случая. Если выражение агрегирует instance, ожидаемый набор также меняется. Проверка полного набора labels полезна: случайно добавленная группировка может раздробить одно событие на несколько или удалить поле, по которому Alertmanager выбирает получателя.

Добавим сценарий, который действительно меняет решение

Следующим тестом можно задать краткое восстановление до границы for. Например, последовательность с единицей на 2m прерывает ожидание, и firing на 3m уже не должен появляться. Отсутствующие samples и stale-маркеры проверяются отдельно: они моделируют другую ситуацию, чем явно записанный нулевой up.

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

Promtool не проверяет маршрут Alertmanager, credentials webhook и реальную доставку сообщения. Эти границы испытывают отдельно на тестовом получателе. Проверка правил закрывает более узкий и важный участок: при заданных данных алерт начинает и заканчивает firing в ожидаемые моменты.

Ещё по теме

• Many-to-many matching not allowed в PromQL: как сопоставить серии
• P95 в Prometheus: как считать задержку по histogram и не усреднять процентили

Продолжить изучение

Хотите построить мониторинг, который помогает находить причины сбоев? Метрики, дашборды и оповещения входят в программу «Prometheus и Grafana: мониторинг и observability».