Мониторинг SLO: дашборд для uptime, ошибок и производительности

Проблема: средние метрики маскируют сбои

Сервис показывает 99,9% uptime, но error budget сгорает за 3 дня. Типичная ошибка — метрики считаются по среднему, а не по процентилям. Пользователи жалуются на тормоза, а дашборд говорит «всё хорошо». За многолетнюю практику мы внедрили мониторинг для десятков проектов — от стартапов до enterprise. Команда видит 99,9% аптайма, но SLO нарушается из-за медленных запросов. Причина — усреднение метрик и игнорирование процентилей. Чтобы этого избежать, нужен дашборд, который за 5 секунд ответит: выполняем ли мы SLO прямо сейчас? Ниже — практический гайд по его построению, который сократит время на инциденты и снизит затраты на поддержку.

Какие метрики обязательны на SLA-дашборде?

Базовый набор: текущий uptime за месяц, error budget (остаток в минутах), P50/P95/P99 response time, error rate в разрезе эндпоинтов. Дополнительно — burn rate и аннотации инцидентов. Мы всегда начинаем с этих показателей и добавляем кастомные метрики под конкретный сервис. Включение процентилей, а не средних, сразу выявляет «хвосты» задержек, которые реально влияют на пользователей.

Расчёт error budget и burn rate

Error budget — допустимое время простоя за период SLO. Например, при SLO 99,9% месячный бюджет = 43 минуты. Следить нужно за его расходом и скоростью выгорания (burn rate). Формула burn rate:

( rate(http_requests_total{status=~"5.."}[1h]) / rate(http_requests_total[1h]) ) / (1 - 0.999) 

Burn rate > 14.4 означает, что при текущем темпе бюджет сгорит за 2 дня. Это сигнал остановить релизы и чинить стабильность. Подход описан в SRE Workbook. Внедрение этой метрики позволяет реагировать превентивно, экономя время и ресурсы команды.

Почему burn rate — ключевая метрика для SLO?

Без burn rate вы узнаёте о проблеме, когда error budget уже на нуле. Burn rate показывает скорость расходования бюджета. Если она превышает 14.4, у вас максимум 2 дня до нарушения SLA. Это позволяет реагировать превентивно, а не постфактум. В наших проектах эта метрика спасла несколько релизов от провала и сократила среднее время восстановления (MTTR) на 40%.

Структура дашборда: три уровня отображения

Техническая панель (для разработчиков)

• Текущий uptime за месяц (например, 99,94%)
• Оставшийся error budget в минутах/часах
• Статус сервиса: OK / DEGRADED / DOWN (большой цветной индикатор)
• График uptime за последние 30/90 дней
• P50/P95/P99 response time — временной ряд
• Error rate — временной ряд с аннотациями инцидентов
• Breakdown по эндпоинтам: какие самые медленные
• Breakdown по регионам/ДЦ
• Последние инциденты с длительностью

Управленческая панель (для бизнеса)

Агрегированные показатели за месяц: общий аптайм, количество инцидентов, среднее время восстановления (MTTR). Графики упрощены, без избыточной детализации.

Публичный Status Page

Минимальный набор: текущий статус сервиса, uptime за последние 7 и 30 дней, история инцидентов. Один источник данных, разные фильтры и агрегации.

Пример расчёта error budget для разных SLO

Ключевые метрики и их вычисление

Uptime %:

(1 - sum(increase(http_requests_total{status=~"5.."}[30d])) / sum(increase(http_requests_total[30d]))) * 100 

P95 Response Time:

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]) ) 

Error Budget Burn Rate (1h):

( rate(http_requests_total{status=~"5.."}[1h]) / rate(http_requests_total[1h]) ) / (1 - 0.999) 

Детали синтаксиса — в официальной документации Prometheus.

Сравнение PromQL и встроенных вычислений

PromQL в 2-3 раза быстрее обрабатывает сложные запросы с процентилями, чем встроенные функции Grafana, что напрямую влияет на скорость получения инсайтов.

Процесс внедрения и сроки

1. Аналитика: собираем SLO, требования, источники метрик (1 день)
2. Проектирование: макет дашборда, продумываем фильтры и иерархию (1 день)
3. Реализация: пишем PromQL-запросы, настраиваем панели (2-3 дня)
4. Тестирование: проверяем точность метрик, воспроизводим инциденты (1 день)
5. Деплой и обучение: выкатываем дашборд, обучаем команду (1 день)

Сроки ориентировочно: базовые панели (uptime, response time, error rate) — от 1 до 2 дней; error budget + burn rate — от 1 дня; полный цикл под ключ — от 5 до 7 рабочих дней. Стоимость рассчитывается индивидуально — оценим проект после брифа.

Что вы получаете в результате

• Рабочий дашборд в Grafana с тремя уровнями отображения
• Набор PromQL-запросов для всех метрик (включая SLO-запросы)
• Документацию по эксплуатации и расширению
• Обучение команды (1-2 часа)
• Поддержку в течение месяца после внедрения

Наш опыт: более 7 лет в SRE и мониторинге, более 50 успешных внедрений дашбордов для компаний разного масштаба. Правильно настроенный дашборд сокращает время на выявление проблем и снижает затраты на поддержку.