Алерт Prometheus не срабатывает: выражение, for и пропавшие данные

API несколько минут отвечает медленнее обычного. В Grafana виден всплеск, а алерт Prometheus остаётся неактивным. Увеличивать чувствительность порога рано: сначала нужно понять, существовало ли условие именно в момент вычисления правила и сохранялась ли одна и та же серия достаточно долго.

У алерта есть несколько отдельных этапов. Prometheus загружает файл правил, периодически вычисляет выражение и переводит подходящие серии в firing. Дальше Alertmanager выбирает получателя, учитывает маршрутизацию, группировку и подавления. Отсутствие сообщения в чате само по себе не показывает, на каком этапе потерялось ожидаемое событие.

Важен факт присутствия серии

Для начала используем понятное условие: target API не удаётся опросить. В файле правил оно выглядит так:

groups:
  - name: api-availability
    rules:
      - alert: ApiTargetDown
        expr: up{job="api"} == 0
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Не удаётся опросить API"

Сравнение без модификатора bool оставляет только серии с нулевым up. Значение оставшейся серии тоже равно нулю — и алерт всё равно активен для её labels. Правило реагирует на элементы результирующего вектора, а не на абстрактную «истинность» чисел. Если заменить выражение на up == bool 0, в результате останутся также здоровые targets со значением 0. Для алерта это меняет поведение принципиально.

Откройте выражение в интерфейсе самого Prometheus на нужный момент времени. Сравните labels результата с теми, которые ожидали. Затем в разделе правил убедитесь, что нужная группа действительно загружена, последняя оценка не завершилась ошибкой и выражение совпадает с файлом, который вы редактировали. Ошибка YAML и пустой вектор требуют разных исправлений.

Что отсчитывает for

После первого подходящего вычисления серия становится pending. Она перейдёт в firing, если условие сохранится для того же набора labels на последующих оценках в течение двух минут. Это не требование набрать две минуты плохих значений в сумме. Если на одной из последующих оценок серия перестала удовлетворять условию, накопленное ожидание для этой серии заканчивается.

Допустим, правило вычисляется раз в 30 секунд. Первый нулевой up замечен в 12:00:00, и следующие оценки также возвращают эту серию. Переход в firing ожидается на оценке в 12:02:00. Если в 12:01:30 опрос успешен, последовательность прерывается. Небольшие реальные смещения расписания могут изменить точный момент, поэтому читайте состояние правила вместе с временем его оценки.

Проверьте и labels самого алерта. Подстановка текущего значения в label создаёт новую идентичность при каждом изменении числа. Изменяющееся описание помещайте в annotations; маршрутизирующие labels должны оставаться устойчивыми. Поведение for и annotations важно учитывать ещё при написании правила.

Ноль и отсутствие метрики требуют разных правил

up == 0 помогает, пока target присутствует в конфигурации обнаружения и опрос завершается неудачей. Если вся группа исчезла из service discovery, после обработки устаревания серия перестанет возвращаться. Нулевого значения для сравнения уже нет. Добавим отдельный сигнал отсутствия:

absent_over_time(up{job="api"}[5m])

Выражение вернёт единицу, если за окно вообще не было подходящих samples. Можно использовать его в отдельном правиле с понятным названием. Окно в пять минут уже задаёт ожидание отсутствия; добавленный for: 2m потребует ещё устойчивости результата. Не считайте такое правило мгновенным детектором пропажи.

Есть важная граница: если у API три экземпляра и исчез только один, оставшиеся серии делают общий селектор непустым. Такой запрос не обнаружит потерю конкретной реплики. Для этого нужен стабильный список ожидаемых объектов и сравнение с реально наблюдаемыми. Выбор зависит от задачи: следить за полной пропажей job или за каждой обязательной машиной.

Когда правило уже firing, продолжайте диагностику в Alertmanager: дошёл ли алерт, подходит ли маршрут, действует ли silence или inhibition. Так вы сохраняете ясную причинную цепочку: данные появились, выражение выбрало серию, таймер выдержан, уведомление направлено получателю.

Ещё по теме

• P95 в Prometheus: как считать задержку по histogram и не усреднять процентили
• Rate и increase в Prometheus: считаем запросы и учитываем сброс счётчика

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

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