Алертинг по бюджету ошибок: multi-window multi-burn-rate

1. Чем плохи классические пороги

Классический мониторинг алертит по фиксированному порогу на сырой метрике, и в этом зашит конфликт: один и тот же порог не может быть одновременно чувствительным к резким всплескам и спокойным к мелкому фоновому шуму. Поставить его низко — дежурного будят на шум; поставить высоко — настоящая деградация проходит незамеченной. Куда ни сдвинь, теряешь одну из сторон.

2. Бюджет ошибок и скорость прожигания

Калькулятор скорости прожигания

3. Простой алерт по скорости прожигания (burn rate) и его проблемы

Первый шаг лучше порога на сырой метрике: алерт «скорость прожигания за окно > X». Но у простого одно-оконного варианта остаются два дефекта, которые SRE Workbook разбирает явно.

4. Multi-window multi-burn-rate

Решение из SRE Workbook: для каждого яруса требуем, чтобы порог был превышен одновременно на длинном И на коротком окне. Длинное окно отвечает за смысл («бюджет действительно прожигается с такой скоростью»), короткое — за актуальность («прожигание идёт прямо сейчас, а не закончилось час назад»). Короткое окно делают примерно в 12 раз короче длинного.

Рекомендуемые пары порогов (SLO 99.9%, 30 дней)

Источник параметров: Google SRE Workbook, гл. «Alerting on SLOs». «Бюджет за окно» — доля 30-дневного бюджета, которую успеет съесть прожигание к моменту срабатывания алерта.

5. Критичность (severity): page или тикет

6. Реализация в Prometheus

Долю ошибок за каждое окно считаем заранее через recording rule — это и быстрее, и читабельнее. Затем alerting rule сравнивает уже готовую метрику с порогом по логике «длинное И короткое».

# Recording rule: доля «плохих» событий за окно как single metric.
groups:
  - name: slo:request_error_ratio
    rules:
      - record: job:slo_errors_per_request:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{code=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m]))
      - record: job:slo_errors_per_request:ratio_rate1h
        expr: |
          sum(rate(http_requests_total{code=~"5.."}[1h]))
            / sum(rate(http_requests_total[1h]))

# Быстрый page: 14.4x за 1 час И за 5 минут одновременно.
# 0.001 = бюджет ошибок при SLO 99.9%; 14.4 * 0.001 = 0.0144.
groups:
  - name: slo:burn_rate_alerts
    rules:
      - alert: ErrorBudgetBurnFast
        expr: |
          job:slo_errors_per_request:ratio_rate1h  > (14.4 * 0.001)
          and
          job:slo_errors_per_request:ratio_rate5m  > (14.4 * 0.001)
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "Бюджет ошибок прожигается со скоростью 14.4x"

Числа в выражении: при SLO 99.9% бюджет ошибок равен 0.001, поэтому порог 14.4x — это 14.4 * 0.001 = 0.0144. Полную схему со всеми тремя ярусами строят по той же модели, меняя пары окон и множители из таблицы выше.

7. Компромиссы: на каких осях выбирать окна

SRE Workbook предлагает оценивать любую схему алертинга по четырём осям. Выбор длины окон и порогов — это всегда баланс между ними.

8. Частые ошибки

Рекомендации

Источники и материалы

Карта источников: SRE Workbook держит multiwindow, multi-burn-rate параметры и критерии page/ticket; SRE Book — базу SLO/error budget; Prometheus docs — recording и alerting rules. Числа 14.4x/6x/1x привязаны к workbook-модели 99.9% за 30 дней; для другого SLO, окна бюджета или on-call политики их надо пересчитывать.

• Google SRE Workbook - Alerting on SLOs
• Google SRE Book - Service Level Objectives
• Prometheus - Alerting Rules
• Prometheus - Recording Rules