RED + USE methods: Rate/Errors/Duration vs Utilization/Saturation/Errors

Зачем

«Что мерять?» — первый вопрос на каждом новом сервисе. Без явного фреймворка команда выбирает метрики хаотично: кто-то любит CPU%, кто-то thread count, кто-то DB connections. Через год дашборд выглядит как «80 виджетов, никто не понимает, что зелёное и что красное», и в инциденте on-call тратит первые 5 минут не на диагноз, а на навигацию.

RED (Tom Wilkie, Weaveworks, 2015) и USE (Brendan Gregg, Netflix, 2012) дают минимально необходимый набор метрик для двух разных зрений на систему: услуга-как-чёрный-ящик (RED: Rate / Errors / Duration) и ресурс-как-устройство (USE: Utilization / Saturation / Errors). Применённые вместе, они сжимают дашборд до 8–12 виджетов на сервис и покрывают ~95% типовых проблем. Google SRE Book формализовал гибрид как Golden Signals (Latency, Traffic, Errors, Saturation) — по сути RED + одна метрика из USE.

Тема обязательная: без RED+USE невозможно ни нормально настроить SLO, ни поймать leading indicators до того, как пользователь увидит 5xx.

Mental model

Две оси наблюдения, взаимодополняющие, не взаимозаменяемые:

• RED — взгляд клиента: «как нам платят». Запросы идут (Rate), они успешны (Errors), и быстро (Duration). Это lagging indicator — он фиксирует, что user impact уже произошёл.
• USE — взгляд оператора: «что внутри устаёт». Ресурс занят (Utilization), очередь растёт (Saturation), железо сыпется (Errors). Saturation — это leading indicator: он горит до того, как RED начинает деградировать.

Главный мысленный приём: utilization ≠ saturation. CPU 90% busy без очереди — это полная загрузка без замедления (хорошо). CPU 50% busy с run queue = 20 — это backpressure (плохо). Наивный мониторинг «disk busy < 80% — ОК» промалчивает там, где iostat avgqu-sz = 20 уже кричит. USE-saturation ловит именно этот класс невидимых для RED проблем.

Третья E (Errors) у обоих фреймворков общая — потому что failures одинаково важны и снаружи (HTTP 5xx), и внутри (ECC errors на RAM, EIO на диске, connection_failures на pool).

Что на диаграмме

На холсте — каноническая трёхзонная конфигурация observability:

• Слева — API service (RED view). Клиенты → LB → инструментированный API (http_requests_total, http_request_duration_seconds), который экспортирует три метрики ровно по фреймворку RED: rate (counter на запросы), errors (rate of 5xx по status label), duration (histogram с buckets, чтобы считать histogram_quantile(0.99, ...)).
• Справа — DB host (USE view). Postgres + postgres_exporter + node_exporter отдают USE на каждый критичный ресурс: CPU (util / loadavg / cfs_throttled), mem (util / swap_in / OOM counter), disk (util / avgqu-sz / EIO+SMART), net (NIC util / backlog drops / CRC), и отдельной нодой — DB connection pool (busy / waiters / connection_failures).
• Снизу — observability stack. Prometheus скрейпит /metrics каждые 15s, Grafana рисует «RED top panel + USE bottom panel», Alertmanager шлёт multi-window burn-rate алерты в PagerDuty.
• Слева внизу — worker pool. Иллюстрация USE-адаптации на background-обработку: queue depth = saturation, busy/total workers = utilization, failed jobs = errors.

Рёбра — это либо реальный data flow (client → LB → API → pool → DB), либо scrape-pull (Prometheus → каждая метрическая нода). Кнопка [DECISIONS] закреплена на нодах api и use-pool — там лежат ADR-ы по выбору фреймворка и по обязательности USE на pool.

Сценарии

Нормальная нагрузка, 1000 RPS на API. API инкрементирует counter (rate), считает {status=~"5.."} ratio (errors), кладёт latency в histogram bucket (duration). Prometheus pulls /metrics каждые 15s. Grafana через PromQL рисует ровно три виджета: sum(rate(...)) → 1000/s, error ratio → 0.01%, histogram_quantile(0.99, ...) → 180ms. Operator видит «зелёное» за 2 секунды без необходимости понимать бизнес-домен. Это контраст к дашборду из 30 виджетов с thread count, GC pauses, heap usage — где никто не знает, какие из них важны.

Traffic spike с 1000 до 2500 RPS после маркетингового email. RED держится: p99 поднялся 180→350ms, всё ещё в SLO, errors 0.01%. Но USE на disk показывает: util 50→85% (ОК) и одновременно avgqu-sz = 20 (saturation — queue растёт). USE на pool: 20/20 busy, 8 waiters в очереди. Alertmanager на правиле db_pool_waiters > 5 for 60s шлёт warning. On-call открывает USE-дашборд, видит disk saturation, находит root cause (отсутствующий индекс на orders.user_id), накатывает фикс за 5–10 минут до того, как RED начал бы fairil-ить с connection_acquire_timeout → 5xx. Это и есть leading vs lagging: saturation предсказала, errors констатировала бы.

Black Friday: 1000 → 2000 RPS. Top panel дашборда (RED) показывает лёгкую деградацию p99 180→280ms. Bottom panel (USE) одновременно загорается: CPU saturation (k8s CFS throttling), queue.depth с 50 ушла на 800, pool 18/20 близко к насыщению. Composite multi-burn-rate alert триггерит page. On-call видит story прямо на дашборде: traffic ↑ → CPU sat → queue piling → pool near-sat. Запускает HPA scale-out (2→6 pods для API, 5→15 для workers), saturations clear за 2 минуты, RED никогда не пробивает SLO. Это контраст: на RED-only дашборде оператор увидел бы p99=280ms (в SLO, нет алерта), инцидент рос бы до тех пор, пока errors не прорвались — и тогда уже было бы поздно.

Trade-offs (ADR)

На диаграмме закреплены два ключевых решения через кнопку [DECISIONS]:

ADR-RED-001: RED для services, USE для resources — обязательный baseline. Выбор framework делает дашборд предсказуемым для всех команд. Правила распределения: HTTP/gRPC services → чистый RED; stateful компоненты (БД, кэш, очередь) → RED на интерфейс + USE на внутренние ресурсы; container/VM/host → чистый USE; external API dependency → RED (внутрь не контролируешь); worker pool/pipeline → USE с queue depth как saturation. Дашборд жёстко ограничен 8–12 виджетами; 13-й виджет требует defending: «какой incident этот widget помог бы поймать».

ADR-RED-002: Histogram, не summary — почему histogram_quantile победил. Summary считает quantile клиент-сайд и не allows aggregate между pods (квантиль не аддитивен). Histogram отдаёт buckets, и histogram_quantile() считает любой percentile, в любом окне, по любой агрегации. Для SLO burn-rate alerts через histogram_quantile(0.99, sum(rate(..._bucket[5m])) by (le)) < 250ms это обязательное условие. Native histograms (Prometheus 2.40+) дают ~1% precision на любом percentile при 8x меньшем storage — рекомендуется переход когда cluster ready.

ADR-USE-001: USE на DB connection pool — mandatory, не optional. Pool exhaustion — самая частая дыра в production observability. RED на API долго показывает «всё ОК», пока pool waiters накапливаются часами, а потом cascading failure. Обязательны три метрики: db_pool_connections_busy, db_pool_connections_idle, db_pool_waiters_count. Алерт: waiters > 0 for 60s → warning, > 5 for 60s → page. Pool size считается по little's law (pool_size = throughput * latency), не «с запасом» — большой pool прячет slow queries и переносит проблему на max_connections DB.

Дополнительные неявные трейд-оффы:

• Cardinality — user_id label на RED rate легко даёт 10M unique series и убивает Prometheus. Для cardinality use traces (Tempo/Jaeger), для aggregates use metrics.
• Scrape interval — 15s стандарт; 5s даёт лучшую precision но утраивает storage; 60s экономит, но пропускает короткие spikes.
• Bucket layout для histogram — слишком крупные buckets теряют precision на хвосте; слишком мелкие раздувают cardinality. HTTP обычно 5ms..10s exponential, DB queries 0.5ms..5s.

Реальные системы

• Linkerd / Istio default dashboards — чистый RED на каждый сервис и каждый mesh edge. Tom Wilkie (автор RED) теперь в Grafana, и они продвигают это как стандарт.
• Prometheus + Grafana — канонический стек: node_exporter отдаёт USE на host, cAdvisor — USE на контейнер, postgres_exporter / redis_exporter / kafka_exporter — RED+USE на stateful сервисы.
• AWS CloudWatch Container Insights — фактически RED+USE на ECS/EKS workloads (Container CPU/MemoryUtilization, RunningTaskCount, request count, latency).
• Datadog APM — trace.http.request.duration (RED.Duration), trace.http.request.errors (RED.Errors), system.cpu.user (USE.U) — ровно та же ось наблюдения, просто rebranded.
• Brendan Gregg's USE checklist — оригинал (https://brendangregg.com/usemethod.html) содержит ready-made таблицы команд Linux/Solaris/FreeBSD для util/sat/err каждого ресурса. Канонический референс.
• Google SRE Book Ch.6 «Monitoring Distributed Systems» — определяет Golden Signals и связывает их с SLO/SLI/error budgets.

Anti-patterns

• CPU% как главная метрика — это USE.Utilization без Saturation. CPU 90% сам по себе ОК, если нет run queue; CPU 50% при loadavg / nproc > 1 — проблема. Использовать loadavg / nproc или k8s container_cpu_cfs_throttled_seconds_total.
• Mean latency — прячет хвосты. При p99=2s mean может быть 200ms. Использовать p50/p95/p99/p99.9 на histogram, никогда average.
• Дашборд из 80 виджетов — никто не смотрит, on-call в инциденте не найдёт корень. RED+USE сжимает до 10–15.
• Errors = только 5xx — много real errors маскируются как 200 (slow loris, partial responses, business validation fails, retries из retry-storm). Считать по бизнес-критериям, не только по HTTP status.
• RED без USE на DB pool — самая частая дыра. Pool exhaustion внезапно обрушит все RED метрики, без ранних сигналов.
• High-cardinality labels на RED rate (user_id, request_id) — миллионы unique series, Prometheus OOM. Для cardinality use traces, для aggregates use metrics.
• Summary вместо histogram для request duration — нельзя aggregate между pods, нельзя ретроспективно менять percentile, нельзя правильный SLO burn-rate alert.
• Watching utilization for capacity planning, not saturation — utilization имеет потолок 100%, и за ним просто остаётся 100%. Saturation растёт до бесконечности и показывает headroom за пределом полной загрузки.
• «Зелёные графики = всё хорошо» — without saturation alerts, зелёный RED при saturation > 0 — это просто запаздывающая red flag.

Когда НЕ использовать

• Чистый batch / offline. Если pipeline считает раз в сутки, RED не имеет смысла (rate бесполезен, duration редко наблюдаем). Используйте job-level метрики: job_last_success_timestamp, job_duration_seconds, job_records_processed.
• Embedded / IoT / firmware с ограниченной памятью на устройстве. Histograms по 15 buckets * labels съедают RAM, который вам не принадлежит. Используйте sample-based + central aggregation.
• CLI tools и одноразовые скрипты. Метрики стоят инфраструктуры, CLI её не имеет. Достаточно exit code + stderr.
• Pre-PMF prototypes. До product-market fit observability оверкилл; logs + uptime check достаточно. RED+USE начинается с момента, когда у вас есть on-call ротация.
• Когда нет on-call. Метрики без алертов и без человека, который их читает — это просто disk usage. RED+USE имеет смысл только когда есть кому реагировать.

Дальше читать

• [CONCEPT]sli-slo-sla — как из RED-метрик строятся SLO и error budgets, multi-window burn-rate alerts
• [CONCEPT]observability-pillars — связка metrics + logs + traces, где cardinality проблема и почему traces решают её
• [CONCEPT]numbers-to-know — какие p99/throughput считать «нормальными» для disk / network / DB
• Tom Wilkie — RED method (оригинал): https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/
• Brendan Gregg — USE method (оригинал): https://brendangregg.com/usemethod.html
• Google SRE Book Ch.6 «Monitoring Distributed Systems» — Golden Signals
• Brendan Gregg, "Systems Performance" 2nd ed (2020) — USE method глава целиком, плюс таблицы tool-ов на Linux
• Cindy Sridharan, "Distributed Systems Observability" — связь RED с three pillars
• PromCon talks — практические доклады по RED+USE на Prometheus