Как настроить алерт на основе burn rate error budget (быстрое и медленное "прожигание") и зачем нужны именно два окна, а не одно?

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

Burn rate — это скорость расхода error budget относительно номинальной скорости, допустимой для выполнения SLO за период; используют два алерта с разными окнами и порогами — "fast burn" (короткое окно, высокий порог, для быстрой реакции на серьёзную деградацию) и "slow burn" (длинное окно, более низкий порог, для постепенных, но системных проблем), чтобы ловить оба типа деградации без избыточного шума.

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

если SLO — 99.9% за 30 дней, то "нормальная" скорость расхода budget — 0.1% ошибок равномерно растянутых на 30 дней. Burn rate 1x означает, что budget закончится ровно к концу периода при неизменной скорости; burn rate 10x означает, что budget истощится в 10 раз быстрее (то есть примерно за 3 дня), что требует немедленной реакции. Короткое окно (например, 5–10 минут) хорошо ловит резкие всплески, но может шумно реагировать на короткие флуктуации; длинное окно (1–6 часов) устойчиво к шуму, но реагирует медленнее.

Пример кода

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

# Fast burn: высокая скорость расхода budget, короткое окно
- alert: ErrorBudgetFastBurn
  expr: |
    (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))) > (14.4 * 0.001)
  for: 2m
  labels:
    severity: critical
# Slow burn: умеренная, но устойчивая скорость расхода budget
- alert: ErrorBudgetSlowBurn
  expr: |
    (sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h]))) > (3 * 0.001)
  for: 30m
  labels:
    severity: warning

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

• Практика. стандартный паттерн (популяризованный Google SRE) — использовать комбинацию короткого и длинного окна для каждого уровня чувствительности, причём алерт срабатывает только при одновременном превышении порога burn rate в обоих окнах — это снижает число ложных срабатываний от кратковременного шума, сохраняя быструю реакцию на реальные устойчивые деградации.
• Практика. Коэффициенты 14.4x и 3x — типичные значения из практики Google SRE workbook для SLO 99.9%; при реальном внедрении их нужно адаптировать под конкретный SLO и период, а не копировать бездумно.

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

• Частые ошибки. использовать только одно длинное окно, из-за чего реакция на серьёзную, но быстро развивающуюся проблему (например, полная недоступность сервиса) приходит с опозданием в час или больше; использовать только короткое окно, что создаёт шумные алерты на любые секундные колебания трафика; не привязывать пороги burn rate к реальному SLO сервиса, а использовать одинаковые "универсальные" цифры для всех сервисов независимо от их целей.