Как бороться с flapping-алертами (алерт постоянно переключается между firing и resolved) кроме увеличения порога?

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

Кроме повышения порога, против flapping помогают: увеличение for (устойчивость условия), использование гистерезиса (разные пороги для срабатывания и для сброса), агрегация метрики по более широкому окну или по группе инстансов вместо одного, а также группировка/подавление повторных уведомлений в Alertmanager через group_interval и repeat_interval.

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

flapping обычно возникает, когда метрика колеблется около одного и того же порога — алерт то срабатывает, то гаснет при каждом пересечении. Гистерезис решает это через два разных условия: например, алерт срабатывает при превышении 90%, но гаснет только при падении ниже 70%, что создаёт "мёртвую зону" и не даёт метрике многократно пересекать одну и ту же границу.

Пример кода

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

# Гистерезис через два отдельных правила с разными порогами
- alert: HighMemoryUsage
  expr: memory_usage_percent > 90
  for: 5m
- alert: HighMemoryUsageRecovering
  expr: memory_usage_percent > 70
  for: 5m

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

• Практика. если метрика по природе шумная (например, latency отдельного инстанса под низкой нагрузкой), часто эффективнее агрегировать её по большему числу источников (avg by (service) вместо by (instance)) или удлинить окно агрегации (rate(...[15m]) вместо [1m]) — это сглаживает случайный шум без потери чувствительности к реальным деградациям. В Alertmanager group_interval и repeat_interval не устраняют сам flapping состояния в Prometheus, но ограничивают частоту повторных уведомлений о той же проблеме.
• Практика. При использовании единого порога 80% метрика, колеблющаяся между 75% и 85%, создаёт десятки переключений статуса за час; при разделении на "вход" 90% и фактическое наблюдение, что алерт снимается только ниже значимо иного уровня, количество переключений резко снижается, что можно проверить по числу событий ALERTS в истории Alertmanager.

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

• Частые ошибки. решать flapping только через увеличение порога, что снижает чувствительность алерта к реальным, но менее выраженным проблемам; не различать flapping из-за шумной метрики и flapping из-за реальной нестабильности системы (например, настоящий циклический рестарт сервиса) — во втором случае нужно чинить саму причину, а не "успокаивать" алерт.