Мониторинг HTTP API. RED-метрики, latency и error budget на практике

Когда HTTP API начинает деградировать, пользователи обычно видят только симптомы: страницы грузятся медленнее, запросы периодически падают, интерфейс «подвисает» или часть функций перестаёт отвечать. При этом сама инфраструктура может формально считаться рабочей.

Задача мониторинга — не просто фиксировать факт «сервис жив», а понимать качество его работы под реальной нагрузкой.

Для этого в продакшене часто используют RED-модель и подход error budget.

Почему одного uptime недостаточно

Классический мониторинг уровня «up/down» уже давно недостаточен для API.

Сервис может быть доступен, но при этом:

• отвечать с задержкой в несколько секунд
• периодически возвращать 5xx ошибки
• деградировать только при росте нагрузки
• ломаться в отдельных регионах или у части пользователей

С точки зрения пользователя это уже инцидент, хотя формально сервис «работает».

Поэтому современный monitoring всегда оценивает не только доступность, но и поведение системы.

RED-метрики

RED — это минимальный, но очень практичный набор метрик для HTTP API:

• Rate — количество запросов
• Errors — доля ошибок
• Duration — время ответа

Эти три сигнала дают быструю и понятную картину состояния сервиса без сложных вычислений.

Rate (нагрузка)

Rate показывает, сколько запросов система обрабатывает за единицу времени (RPS / QPS).

Сам по себе рост нагрузки не является проблемой, но он часто становится триггером деградации.

При увеличении RPS может происходить:

• рост нагрузки на CPU и память
• исчерпание connection pool к базе данных
• увеличение очередей запросов
• рост latency из-за конкуренции за ресурсы

Важно всегда анализировать Rate вместе с ошибками и задержками — только так видно реальную картину.

Errors (ошибки)

Errors показывают долю неуспешных запросов.

Обычно сюда относятся:

• HTTP 5xx ошибки
• timeout запросов
• connection reset
• upstream failures

Иногда также учитывают 4xx ошибки, например 429 Too Many Requests, если они связаны с перегрузкой.

Даже небольшой рост error rate (например до 0.5–1%) часто указывает на начинающиеся проблемы в инфраструктуре: базу данных, сеть или зависимые сервисы.

Duration (latency)

Duration показывает время обработки запроса.

Одна из самых частых ошибок в мониторинге — смотреть только среднее значение latency.

Среднее значение может выглядеть нормально, даже если часть пользователей испытывает сильные задержки.

Поэтому в реальных системах анализируют распределение задержек и поведение системы под нагрузкой.

Подробнее про tail latency и почему редкие задержки важнее среднего значения разобрано здесь.

Error budget

Error budget — это допустимый уровень деградации сервиса при заданном SLA.

Например SLA 99.9% означает, что система может иметь ограниченное количество ошибок или простоев в месяц.

Идея проста: сервис не обязан быть идеальным, но обязан укладываться в заранее определённый бюджет ошибок.

Как RED и error budget работают вместе

В реальной эксплуатации эти подходы используются вместе.

Типичная цепочка деградации выглядит так:

• растёт нагрузка (Rate)
• увеличивается latency (Duration)
• растёт количество ошибок (Errors)
• начинает расходоваться error budget

Это позволяет заметить проблему ещё до полного отказа системы.

Почему внешние проверки важны

Внутренний мониторинг может показывать нормальные метрики, даже если пользователи уже сталкиваются с проблемами.

Типичные слепые зоны:

• региональные сбои
• проблемы DNS
• деградация TLS handshake
• сетевые проблемы между зонами

Поэтому дополнительно используют внешние HTTP checks.

Например через Statuser.

Он позволяет:

• проверять API из разных регионов
• отслеживать доступность и latency
• контролировать SSL/TLS сертификаты
• видеть историю инцидентов и простоев

Такие проверки часто позволяют обнаружить проблему раньше пользователей.

Что стоит мониторить у HTTP API

Минимальный практический набор метрик:

• RPS (нагрузка)
• error rate (ошибки)
• latency (время ответа)
• timeout rate
• saturation ресурсов (CPU, memory, connection pool)

Дополнительно в production часто смотрят:

• latency к базе данных
• cache hit ratio
• количество retries
• очередь задач (queue depth)
• состояние circuit breaker

Частые ошибки мониторинга

Одна из самых распространённых проблем — неправильный фокус метрик:

• ориентация только на uptime
• использование только average latency
• отсутствие анализа распределения задержек
• алерты без контекста нагрузки
• отсутствие внешних проверок

Средние значения часто скрывают реальную деградацию системы.

Хорошие алерты

Плохой пример:

• API down

Хорошие примеры:

• latency выше допустимого порога
• error rate выше нормы
• saturation pool > 90%

Такие сигналы позволяют реагировать до того, как произойдёт полный отказ сервиса.

Итоги

RED-модель — это простой и практичный способ мониторинга HTTP API.

Она позволяет быстро понять:

• сколько запросов приходит (Rate)
• насколько стабильно работает система (Errors)
• как быстро она отвечает (Duration)

В сочетании с error budget и внешними проверками это формирует полноценную систему наблюдаемости, которая позволяет ловить деградации до инцидентов и защищать пользователей от реальных проблем.