# Алерт то молчит, то срабатывает: for, pending и keep_firing_for

Диагностика: Алерт то молчит, то срабатывает: for, pending и keep_firing_for. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/prometheus-alert-pending-flapping/
Language: ru

Pending alert не обязательно сломан: for требует, чтобы условие оставалось истинным на последовательных evaluations. Keep_firing_for может удерживать firing после исчезновения условия. Разделите вычисление правила и доставку уведомления через Alertmanager, прежде чем менять порог.

## Сохраните экземпляр alert

Запишите rule expression, for, keep_firing_for, evaluation interval и результирующий labelset. Для Prometheus отдельные наборы labels означают отдельные экземпляры alert. Если динамическое значение попадает в labels и меняется при каждом evaluation, ожидание может начинаться заново. Описательные изменяемые сведения обычно следует рассматривать в annotations, сохраняя стабильную identity. Проверьте результат expression в табличном виде: пустой vector и sample со значением ноль имеют разный смысл в зависимости от самого правила.


[Официальный источник 1](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/).

## Нарисуйте переходы состояния

Условие становится active, затем при наличии for остаётся pending до нужной продолжительности. После firing keep_firing_for может отложить прекращение состояния. Эти интервалы не равны задержке уведомления: Alertmanager отдельно группирует, подавляет и отправляет alerts. Поэтому отсутствие сообщения при firing может относиться к routing или silence, а отсутствие firing — к выражению и evaluations. Сохраните оба слоя в наблюдении, не объединяя их в один таймер «когда придёт оповещение».


[Официальный источник 2](https://prometheus.io/docs/alerting/latest/overview/).

## Разберите прерывистый порог

В учебном правиле for равен 5 минутам. Условие истинно 4 минуты, исчезает, затем возникает снова. Первый эпизод не обязан стать firing. Добавление keep_firing_for относится к удержанию уже сработавшего alert и не заменяет первое ожидание for. Числа показывают логику, а не рекомендуют порог для сервиса. На стенде проверьте также короткий пробел в данных, потому что отсутствие observation может внешне напоминать нормализацию показателя.

| Проверка | Слой проблемы |
| --- | --- |
| Expression пуст | Входные данные или условие |
| Pending не заканчивается | For, labels и непрерывность |
| Firing без сообщения | Alertmanager delivery policy |
| Firing сохраняется | Keep_firing_for или условие |

## Исправьте заданное поведение

Сначала определите, какой эпизод требует реакции: краткий всплеск, устойчивое нарушение или отсутствие измерений. Затем подберите правило и отдельно delivery policy. Не сокращайте for только для получения тестового сообщения в production. Используйте контролируемый synthetic rule или проверку правил, сохраняя цель исходного alert. Keep_firing_for помогает при flapping, но также продлевает состояние после реального восстановления; это последствие должно быть понятно человеку, который читает dashboard и журнал инцидента.

## Проверьте временной сценарий

Сохраните несколько последовательных evaluations с timestamps, labels и состояниями. Затем сопоставьте вход Alertmanager и фактическую delivery decision. Артефакт содержит ожидаемую шкалу и наблюдаемый результат, без утверждений о договорном SLA. После изменения labels или scrape interval повторите тест. Успешный alert должен объяснимо срабатывать и разрешаться по задуманной политике, а не просто один раз отправить сообщение. Такое разделение сокращает ложные исправления, когда причина находится в другом слое оповещения.

Связанные разборы: [gpu monitoring scorecard](/ru/journal/gpu-monitoring-scorecard/); [gpu owner network outage log](/ru/journal/gpu-owner-network-outage-log/).