RED-метод — это подход к мониторингу систем на базе 3 метрик: Rate (частота запросов), Errors (ошибки) и Duration (длительность). Метод был разработан специально для микросервисной архитектуры и request-driven систем. Его часто используют вместе с 4 золотыми сигналами мониторинга в SRE практиках.
В двух словах: RED-метод помогает DevOps и SRE инженерам быстро понять здоровье сервиса через призму пользовательского опыта — сколько запросов обрабатывается, сколько из них падает с ошибками, и как быстро система отвечает.
Если ты работаешь с микросервисами, REST API или distributed systems, RED-метод даст тебе минимальный набор метрик для эффективного мониторинга производительности.
Подробное объяснение
Rate (Частота запросов) — сколько запросов обрабатывает система
Rate показывает количество запросов, которые обрабатывает твой сервис за единицу времени. Обычно измеряется в RPS (requests per second, в секунду) или RPM (requests per minute, в минуту).
Зачем: изменения в Rate часто указывают на проблемы в системе мониторинга. Обычно количество запросов меняется плавно в течение дня, а резкое падение может означать недоступность upstream сервисов, а резкий рост — DDOS атаку или проблемы с load balancer.
Что измерять:
- HTTP-запросы в секунду для приложения. Можно снимать с nginx/ingress
- RPC-вызовы для gRPC сервисов
- Задач/Сообщений в секунду для task/event-driven систем
- Количество SQL запросов в секунду для БД
Пример мониторинга в Prometheus:
# Частота HTTP запросов в секунду
sum(rate(http_requests_total[5m])) by (service, endpoint)
# Частота gRPC вызовов
sum(rate(grpc_server_handled_total[5m])) by (service, method)
Errors (Ошибки) — процент неуспешных запросов
Errors отслеживают долю запросов, которые завершились неудачно. В отличие от простого подсчета ошибок, важно смотреть именно на error rate — процент ошибок относительно общего количества запросов.
Типы ошибок для мониторинга:
- HTTP 4xx и 5xx статус-коды
- Таймауты соединений
- gRPC error codes (UNAVAILABLE, DEADLINE_EXCEEDED)
- Количество записей с уровнем ERROR в логах
Нюанс: 4xx и 5xx ошибки стоит мониторить отдельно. HTTP 404 может быть ожидаемым поведением, а HTTP 500 — критической проблемой (на сервере).
Пример мониторинга в Prometheus:
# Процент HTTP ошибок
sum(rate(http_requests_total{status=~"4..|5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100
# Процент gRPC ошибок
sum(rate(grpc_server_handled_total{grpc_code!="OK"}[5m])) / sum(rate(grpc_server_handled_total[5m])) * 100
Duration (Длительность) — время обработки запросов
Duration измеряет время, которое требуется системе для обработки запроса. Это может быть latency, response time или processing time в зависимости от контекста.
Ключевые особенности:
- Используй процентили (p95, p99) вместо среднего значения
- Медленная ошибка хуже быстрой ошибки для пользователя
- Рассматривай Duration отдельно для успешных и неуспешных запросов
Типичные пороги по Duration:
- p95 < 100ms для критических API
- p99 < 500ms для пользовательских интерфейсов
- p50 < 50ms для real-time систем
Пример мониторинга в Prometheus:
# 95-й процентиль времени ответа
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
# Среднее время обработки успешных запросов
rate(http_request_duration_seconds_sum{status=~"2.."}[5m]) / rate(http_request_duration_seconds_count{status=~"2.."}[5m])
Связь RED-метода с другими подходами
RED-метод тесно связан с 4 золотыми сигналами мониторинга:
| RED-метод | Golden Signals |
|---|---|
| Rate | Traffic |
| Errors | Errors |
| Duration | Latency |
| — | Saturation |
Отличие: RED фокусируется на request-driven системах, а Golden Signals покрывают более широкий спектр систем включая хранилища и batch-обработку.
Освой диагностику проблем на практических примерах
Понимание RED-метрик — это первый шаг к эффективному мониторингу. Но что делать, когда метрики показывают проблему? Попробуй демо-сценарий с реальным инцидентом и научись диагностировать проблемы на практике.
FAQ
Как адаптировать RED-метод для асинхронных систем?
Для event-driven систем адаптируй метрики:
- Rate → сообщения в секунду (queue throughput)
- Errors → failed messages / dead letter queue
- Duration → время обработки сообщения (processing time)
Пример для Kafka:
# Rate: сообщения в секунду
sum(rate(kafka_consumer_records_consumed_total[5m]))
# Errors: сообщения в DLQ
sum(rate(kafka_consumer_records_lag[5m]))
# Duration: время обработки
histogram_quantile(0.95, sum(rate(message_processing_duration_bucket[5m])) by (le))
Как связать RED-метрики с бизнес-KPI?
Создай mapping техническое → бизнес:
- Rate падает → снижение конверсии/продаж
- Errors растут → потерянные пользователи
- Duration увеличивается → ухудшение UX
Измеряй корреляцию между RED-метриками и бизнес-метриками (bounce rate, conversion rate) для обоснования инвестиций в надежность.