RED и USE — какие метрики важны для веб-приложений

RED и USE — две комплементарные методологии наблюдаемости. RED (Rate, Errors, Duration) фокусируется на характерных для сервисов HTTP-запросах. USE (Utilization, Saturation, Errors) — на ресурсах и их состоянии. Для веб-приложения нужно собирать обе группы метрик и уметь быстро связывать их между собой.

RED — что собирать для каждого HTTP/endpoint / сервиса

• Rate (throughput)
  — входящие запросы в секунду (req/s) по сервису и по эндпоинтам: sum(rate(http_requests_total[1m])) by (route)
  — полезно смотреть и успешный/ошибочный поток (split по статусам).

• Errors
  — доля ошибочных ответов: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])
  — классификация по статусам (4xx/5xx), по типам ошибок (DB timeout, upstream 502 и т.д.).

• Duration (latency)
  — перцентили p50/p95/p99 для основных эндпоинтов (histogram или summary): histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))
  — медиана + хвосты — хвосты (p99/p999) часто решают UX/инциденты.

Дополнительно: in-flight requests (concurrency), request size, response size, time-to-first-byte.

USE — что собирать про ресурсы и зависимости

• Utilization (сколько % ресурса занято)
  — CPU utilization per core, memory used/limit, disk I/O utilization, network bandwidth.

• Saturation (степень перегруженности)
  — queue length, runnable threads, connection pool usage, file descriptors used, socket backlog, accept queue, DB connection pool saturation, request queue depth в web-сервере. Важно смотреть не только % использования, но и метрики очередей.

• Errors (ошибки на уровне ресурсов)
  — OOM kills, kernel errors, socket errors, failed syscall counts, disk errors, DB connection failures.

Зависимости и бизнес-метрики

• latency и error rate внешних зависимостей (DB, кеш, third-party APIs).

• cache hit/miss rate, DB query latency, DB replication lag, queue backlog (Kafka lag, RabbitMQ queue length).

• бизнес-метрики: покупки/checkout rate, conversion, active users — они показывают реальный импакт инцидента.

Практические рекомендации по сбору и агрегации

• Инструментируйте сервисы с Request/Trace IDs (correlation_id, trace_id) — связывать логи, метрики и трассы.

• Собирать RED по маршрутам/группам (route или service), но избегать высоко-кардинальных лейблов (user_id, session_id) в метриках.

• Используйте гистограммы (Prometheus histograms + exemplars) для latency; не храните миллионы уникальных series.

• Синтетика (external probes) + RUM для измерения реального UX.

• Храните агрегации (p50/p95/p99) и raw buckets для глубокого анализа.

Alerting (что обычно алертить)

• Error rate > X% на 5–15 минут (например, >1% для API, но порог зависит от SLO).

• p95 / p99 latency выше порога (например p95 > 300–500 ms для критичных API).

• Saturation > 80% или queue length растёт (флаги congestion).

• Burn-rate алерты по error budget.

• Резкий drop в throughput (внезапный пад traffic) — может быть external outage или throttling.

Dashboards и расследование

• «Golden signals» dashboard: rate / errors / latency + CPU/memory + queue depth + dependency health.

• Возможность drill-down: от сервиса → endpoint → pod/instance → trace → logs.

• Связывайте метрики с логами и трайсами: trace_id в логе значительно ускоряет RCA.

Частые ошибки

• алерты на mean latency вместо перцентилей;

• слишком много метрик с высокой кардинальностью;

• отсутствие метрик по очередям и connection pools (saturation);

• отсутствие бизнес-метрик рядом с техническими.

Сочетание RED (пользовательский опыт) и USE (ресурсы/состояние) даёт быстрый и практичный набор для мониторинга веб-приложения: RED показывает симптомы, USE — где искать причину.