Native histograms, SLO и паттерны production-сбоев

GitHub, 2023: SLO-алерт на задержку code-search многократно срабатывал без реакции. Расследование обнаружило: алерт был настроен на среднюю задержку — фикс бага, поднявший p99 с 200 мс до 800 мс, едва сдвинул среднее. SLO был переработан на multi-window p99 burn-rate алерты по паттерну Google SRE Workbook. Следующий инцидент был пойман менее чем за 4 минуты.

Native histograms (Prometheus 2.40+)

Классические гистограммы требуют выбора границ бакетов во время инструментации. Если распределение задержки сервиса смещается — например, медленный путь внезапно начинает доминировать в диапазоне 1–5 с — нужен повторный деплой с другими бакетами.

Native histograms (Prometheus 2.40+, также называемые exponential histograms в OTel) используют логарифмическую шкалу с динамически адаптирующимся разрешением. Каждое наблюдение помещается в бакет шириной ~1% относительной точности — e^(2^-scale) — без какого-либо статического списка границ. Преимущества:

• Никакой ручной настройки бакетов.
• Равномерная точность p99 по всему диапазону задержки (не только вблизи SLO).
• Аналогичная стоимость хранения по сравнению с хорошо настроенной классической гистограммой.
• Полная совместимость с PromQL: histogram_quantile работает так же.

Exponential histograms OTel работают идентично и являются дефолтом для новой инструментации метрик в OTel SDK.

Совместимость: некоторые старые storage-бэкенды (Cortex < 1.15, Thanos < 0.32) требуют обновления версий для чтения native histograms. Проверь storage-слой перед переходом.

Почему усреднение p99 по репликам неверно

Усреднение предварительно вычисленных перцентилей (summary-метрики) по репликам — известный антипаттерн:

Пример: реплика A обслуживает 100 запросов, все по 100 мс. Реплика B обслуживает 100 запросов, все по 1000 мс. p99 у A = 100 мс; p99 у B = 1000 мс; их среднее = 550 мс. Истинный p99 объединённых 200 запросов = 1000 мс (ранг 199 из 200, выше 99-го перцентиля). Среднее ошибается почти вдвое.

Правильный паттерн: гистограммы эмитируют per-replica счётчики бакетов; sum by (le) (rate(...)) агрегирует их во время запроса; histogram_quantile вычисляет истинный fleet-wide перцентиль из агрегированных счётчиков. Точность ±половина бакета. Никакой изоляции по репликам.

RED питает SLO error budget

SLO — это обещание: 99,9% запросов успешно завершаются в пределах 200 мс за 30 дней. Duration и Errors из RED — это именно те метрики, которые наполняют это обещание.

• SLO по доступности: 1 - rate(errors[window]) / rate(total[window]) — «99,9% запросов не должны возвращать 5xx»
• SLO по задержке: histogram_quantile(0.99, ...) < 0.200 — «99-й перцентиль должен быть ниже 200 мс»
• Error budget: оставшиеся минуты или количество запросов до нарушения SLO за месяц.

Без RED-инструментации у тебя нет SLO — есть желание.

Multi-window burn-rate alerting (Google SRE Workbook): алертить, когда error budget сжигается слишком быстро одновременно на двух окнах:

• 1-часовое окно (fast burn): ловит внезапные всплески (неудачный деплой).
• 6-часовое окно (slow burn): ловит медленные регрессии, которые пороговые алерты пропускают.

Пороговый алерт на абсолютное значение p99 («сработать если p99 > 200 мс») пропускает медленные регрессии (p99 растёт со 150 до 190 мс за две недели, всегда ниже порога) и выдаёт false positive при кратких всплесках. Burn-rate алерты ловят оба сценария.

Паттерны production-сбоев в RED+USE

GitHub 2023 (алерт на среднюю задержку): SLO-алерт на среднюю задержку. Регрессия подняла p99 с 200 до 800 мс; среднее сдвинулось с 45 до 55 мс. Алерт не сработал. Фикс: переход на p99 burn-rate алерты с 1h коротким + 6h длинным окнами по SRE Workbook.

Cloudflare 2022 (cardinality explosion): Новый label на request_duration вызвал OOM Prometheus-серверов. Задержка вычисления правил выросла с 100 мс до 4+ с, маскируя алерты сервисов. Собственная метрика Prometheus prometheus_tsdb_head_series была ведущим сигналом — но алерта на неё не было. Фикс: per-team cardinality budget, принудительный в CI; мета-мониторинг собственного RED Prometheus.

Stripe 2024 (PSI memory pressure невидима для free-RAM): Webhook-воркер завис на 11 минут. Дашборды free-RAM показывали 500 МБ свободных. PSI memory full был на уровне 90% — ядро трэшило reclaim. Фикс: перенос saturation-алертинга с MemAvailable < threshold на PSI-алертинг; следующий инцидент пойман за 30 секунд.

Discord 2023 (рост задержки вычисления правил): Рефактор перенёс hot label с одной метрики на две. Cardinality удвоилась молча. Задержка вычисления правил Prometheus выросла с 100 мс до 4 с за две недели, задерживая алерты во время инцидента, видимого пользователям. Фикс: задержка вычисления правил добавлена как первоклассная панель в мета-мониторинг дашборд.