Сообщить об ошибкеКороткий ответ
Burn rate — это скорость, с которой расходуется error budget относительно равномерного темпа за весь период SLO; алерт на быстрое сгорание (fast burn, например, весь месячный бюджет будет исчерпан за несколько часов при текущей скорости) требует немедленной реакции, а алерт на медленное сгорание (slow burn, бюджет будет исчерпан за несколько дней) можно обрабатывать в рабочем порядке.
Как это работает подробнее
если SLO 99.9% за 30 дней, равномерный расход бюджета означает, что за 1 час должно "тратиться" около 1/720 месячного бюджета; burn rate = 1 означает именно такой равномерный темп, burn rate = 10 означает, что при таком темпе месячный бюджет будет исчерпан за 3 дня вместо 30 — именно множитель burn rate, а не абсолютное значение доли ошибок, определяет срочность реакции.
Пример / кейс
Ожидаемое поведение: алерт срабатывает только при устойчиво высоком burn rate на обоих окнах одновременно, что отличает реальную быструю деградацию (требующую немедленного реагирования on-call) от короткого единичного всплеска ошибок, который самостоятельно затухает за минуту.
Пример кода
# Fast burn: burn rate > 14.4 на окнах 5m и 1h одновременно (для SLO 99.9% за 30 дней)
(
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
> 14.4 * 0.001
)
and
(
sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h]))
> 14.4 * 0.001
)Что использовать на практике
- Практический подход. Многоуровневые алерты комбинируют короткое и длинное окно наблюдения для каждого уровня чувствительности — например, fast burn алерт проверяет высокий burn rate одновременно на коротком (5 минут) и более длинном (1 час) окне, чтобы не реагировать на кратковременный всплеск, но поймать устойчивую деградацию быстро; slow burn алерт использует более длинные окна (6 часов и 3 дня) с меньшим порогом burn rate, что позволяет заметить медленную, но системную деградацию без паники по мелким всплескам.
Подводные камни
- Частые ошибки. Алертить на абсолютную долю ошибок без привязки к burn rate и оставшемуся бюджету, из-за чего одинаковая доля ошибок при разных SLO даёт неверную срочность; использовать только одно окно наблюдения, что либо даёт слишком много ложных срабатываний (короткое окно), либо слишком медленную реакцию (только длинное окно); не пересматривать пороги burn rate после изменения самого SLO.