В этом материале
Pending alert не обязательно сломан: for требует, чтобы условие оставалось истинным на последовательных evaluations. Keep_firing_for может удерживать firing после исчезновения условия. Разделите вычисление правила и доставку уведомления через Alertmanager, прежде чем менять порог.
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 со значением ноль имеют разный смысл в зависимости от самого правила.
Нарисуйте переходы состояния
Условие становится active, затем при наличии for остаётся pending до нужной продолжительности. После firing keep_firing_for может отложить прекращение состояния. Эти интервалы не равны задержке уведомления: Alertmanager отдельно группирует, подавляет и отправляет alerts. Поэтому отсутствие сообщения при firing может относиться к routing или silence, а отсутствие firing — к выражению и evaluations. Сохраните оба слоя в наблюдении, не объединяя их в один таймер «когда придёт оповещение».
Разберите прерывистый порог
В учебном правиле 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; gpu owner network outage log.