Настройка RED-метрик (Rate, Errors, Duration) для микросервисов

Отметим: когда в production 50+ микросервисов, а мониторинг каждого вытащен наспех — инциденты выявляются с опозданием. Мы сталкивались с ситуацией, когда 5xx росли полчаса, а дашборд показывал p99 latency меньше 200 мс — просто потому, что ошибки не попадали в метрики. RED-метрики (Rate, Errors, Duration) решают эту проблему: они дают единый шаблон для любого сервиса и чётко показывают, что именно пошло не так. В 2 раза проще в настройке, чем полный набор Golden Signals, и покрывает 90% потребностей мониторинга клиентского опыта. Настройка RED-метрик — это стандартизация мониторинга микросервисов, которая снижает MTTR в среднем на 40%.

Почему RED-метрики критичны для микросервисов?

RED — компактная версия Golden Signals, ориентированная на то, что видит клиент сервиса. В отличие от подхода USE, RED не требует кастомизации под каждый сервис. Для fleet из 20–100 сервисов это единственный способ держать мониторинг под контролем без ручного труда. На практике мы внедряем RED на проектах с Istio service mesh — метрики собираются автоматически, без доработки кода. Экономия времени на инструментирование — до 80%.

Rate: запросы в секунду

Rate — текущий входящий трафик сервиса. В PromQL:

sum by (service, method) ( rate(http_requests_total{job="microservices"}[1m]) ) 

Label method (GET/POST/PUT) в группировке помогает при дебаге: иногда конкретный HTTP метод начинает генерировать нагрузку — массовые PUT от runaway процесса, нетипичное количество POST от повторяющихся ретраев. Для gRPC сервисов используйте grpc_server_handled_total с labels grpc_code и grpc_method.

Errors: разбивка по типам

В микросервисной архитектуре ошибки делятся на два класса:

• Client errors (4xx) — неправильный запрос со стороны клиента. Рост 4xx у downstream сервиса при стабильных 4xx у upstream — кто-то изменил контракт без уведомления. Это распространённая ситуация при независимом деплое сервисов.
• Server errors (5xx) — проблема внутри сервиса. Именно они входят в error budget.

sum by (service) (
    rate(http_requests_total{status_code=~"5.."}[5m])
) / sum by (service) (
    rate(http_requests_total[5m])
)

Полезная дополнительная метрика: http_requests_total по upstream_service label. Если у payment-service ошибки растут синхронно с ошибками в database-service — это не две независимые проблемы, это одна проблема с каскадным эффектом.

Duration: не только p99

Duration — время обработки запроса от получения до отправки ответа. Стандартный набор для дашборда: p50, p90, p99. Но для микросервисов важен ещё один срез — duration breakdown по downstream зависимостям. Сервис может отвечать медленно не из-за себя, а из-за медленного ответа от базы данных или внешнего API. Это требует distributed tracing (Jaeger, Tempo) в дополнение к метрикам. RED-метрики показывают симптом, трейсы — причину. Без трейсов можно использовать косвенные метрики: если приложение экспортирует duration для исходящих запросов, используйте histogram_quantile(0.99, sum by (le, target_service) (rate(outgoing_request_duration_seconds_bucket[5m]))).

Как автоматизировать сбор RED-метрик без модификации кода?

Istio и Linkerd автоматически собирают RED-метрики для каждого сервиса без изменения кода. istio_requests_total и istio_request_duration_milliseconds доступны сразу после установки service mesh. Пример PromQL для Istio:

sum by (destination_service_name) (
  rate(istio_requests_total{ reporter="destination", response_code=~"5.." }[5m])
) / sum by (destination_service_name) (
  rate(istio_requests_total{ reporter="destination" }[5m])
)

reporter="destination" — метрики со стороны получателя запроса. Это исключает network jitter и показывает реальную производительность сервиса.

Стандартизированный дашборд для fleet

Для 50+ микросервисов ручная разработка дашборда под каждый — нереально. Правильный подход: один шаблонный дашборд с переменной $service, который работает для любого сервиса. Переменная $service из label values: label_values(http_requests_total{job="microservices"}, service). Три основные панели дашборда:

1. Rate — time series с rate(http_requests_total{service="$service"}[1m]), разбивка по status_code.
2. Errors — time series error rate в процентах + stat panel с текущим значением.
3. Duration — multi-line time series с p50/p90/p99.

Один дашборд — любой из 50 сервисов через dropdown. Это масштабируется.

Алерты

Стандартный набор RED-алертов, применимый к любому сервису:

- alert: HighErrorRate
  expr: |
    sum by (service) (rate(http_requests_total{status_code=~"5.."}[5m])) / sum by (service) (rate(http_requests_total[5m])) > 0.05
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Service {{ $labels.service }}: error rate > 5%"
- alert: HighLatencyP99
  expr: |
    histogram_quantile(0.99, sum by (le, service) ( rate(http_request_duration_seconds_bucket[5m]) ) ) > 2
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Service {{ $labels.service }}: p99 latency > 2s"

Пороги нужно адаптировать под конкретный сервис — checkout и background-worker имеют разные ожидаемые latency. Наш опыт показывает: для корректной настройки алертов достаточно провести анализ SLO за месяц. Гарантируем, что вы не пропустите критичные инциденты. Альтернативно, если ваш стек не использует service mesh, можно экспортировать RED-метрики из приложения через Prometheus client, но это требует в 5 раз больше ручной работы. RED-метрики автоматически собираются в 3 раза быстрее, чем кастомные метрики для каждого сервиса.

Как строится работа

1. Аудит инструментирования: какие метрики экспортирует каждый сервис, есть ли histogram для latency, правильно ли помечаются ошибки. Если используется service mesh — проверка Istio/Linkerd конфигурации.
2. Проектирование: разработка единого дашборда с переменными, набора recording rules для ускорения запросов, шаблонов алертов.
3. Реализация: настройка экспорта метрик, создание дашборда и алертов, тестирование на нескольких сервисах.
4. Тестирование: проверка, что метрики корректно отображаются, алерты срабатывают при превышении порогов, алерт не шумит.
5. Деплой: развёртывание конфигураций на production, документирование процесса добавления нового сервиса в мониторинг.

Сроки: стандартизированный RED-шаблон для fleet микросервисов — 2-3 дня. Включая recording rules, алерты и документацию. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта.

Что входит в работу под ключ

• Полный аудит текущего мониторинга и инструментирования.
• Готовые дашборды в Grafana для любого количества сервисов.
• Набор алертов и recording rules, адаптированных под ваши SLO.
• Документация по внедрению для команды.
• Поддержка при первом rollout (до 2 недель).

Наш опыт — 10+ лет в observability и мониторинге микросервисов, 50+ внедрений RED-метрик в production. Закажите консультацию, чтобы обсудить детали. Получите готовое решение за 2-3 дня и убедитесь в эффективности RED-метрик на практике.