Как устроено Prometheus alerting rule изнутри — что означают состояния `pending` и `firing` и за что отвечает поле `for`?

Короткий ответ

Когда выражение правила впервые становится истинным, алерт переходит в состояние pending; если оно остаётся истинным дольше времени, указанного в for, алерт переходит в firing и фактически отправляется в Alertmanager; если условие перестаёт выполняться до истечения for, алерт возвращается в inactive без отправки уведомления.

Как это работает подробнее

Prometheus проверяет alerting rules с интервалом evaluation_interval; на каждой проверке, если выражение истинно, он либо создаёт новый алерт в pending (если его не было), либо проверяет, не истекло ли время for с момента первого срабатывания. Только после непрерывного истинного состояния на протяжении for алерт реально "отправляется" — до этого никакого уведомления дежурному не приходит.

Пример кода

config.yamlКопировать

- alert: HighLatency
  expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 1
  for: 5m
  labels:
    severity: warning

Что использовать на практике

• Практика. for — это основной встроенный механизм защиты от кратковременных всплесков и шумных алертов; значение подбирают исходя из того, насколько быстро реально нужно реагировать (для критичных пользовательских алертов — несколько минут, для менее срочных — 15–30 минут) и насколько метрика "дёргается" в норме. Слишком большое for увеличивает время до реального уведомления (MTTD), слишком маленькое — возвращает проблему шумных алертов.
• Практика. В Prometheus UI на вкладке /alerts сразу после превышения порога алерт появится со статусом PENDING (жёлтый), и только через 5 минут непрерывного превышения перейдёт в FIRING (красный) и будет отправлен в Alertmanager — это поведение можно воспроизвести, искусственно вызвав нагрузочный всплеск и наблюдая за переходами статуса.

Подводные камни

• Частые ошибки. путать pending с реально отправленным алертом и удивляться, почему уведомления нет, хотя в UI Prometheus алерт уже "горит оранжевым"; ставить одинаковый for для всех алертов независимо от критичности, не различая "разбудить дежурного ночью" и "создать тикет на следующий день"; не учитывать, что evaluation_interval сам по себе добавляет задержку — если он равен 1 минуте, а for: 1m, то фактическая задержка обнаружения может быть ближе к 2 минутам.