Налаштування 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-метрик на практиці.