Как спроектировать дашборд для дежурного инженера по методологии RED или USE и в чём разница между этими подходами?

Короткий ответ

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

Как это работает подробнее

RED-метрики строятся вокруг запросов — например, rate(http_requests_total[5m]) (Rate), rate(http_requests_total{status=~"5.."}[5m]) (Errors), histogram_quantile(0.95, ...) (Duration). USE-метрики строятся вокруг ресурса — Utilization (cpu_usage_percent), Saturation (длина очереди на выполнение, node_load1 относительно числа ядер), Errors (ошибки диска, сетевые drop-ы).

Пример кода

query.promqlКопировать

# RED: Errors
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
# USE: Saturation для CPU (load relative to cores)
node_load1 / count without (cpu) (node_cpu_seconds_total{mode="idle"})

Что использовать на практике

• Практика. RED хорошо подходит для верхнего уровня дашборда сервиса (отвечает на вопрос "сервис обслуживает пользователей нормально?"), USE — для нижнего уровня инфраструктуры под этим сервисом (отвечает на вопрос "не упирается ли сервис в ресурс?"). Комбинированный дашборд дежурного обычно показывает RED-панели сверху как "первый взгляд" и USE-панели ниже для перехода к причине при обнаружении проблемы.
• Практика. Если RED-панель показывает рост error rate у сервиса checkout, а USE-панель того же узла показывает saturation (load) значительно выше числа ядер, это указывает на нехватку CPU как вероятную причину, что сразу определяет следующий шаг — масштабирование или оптимизацию, а не бессистемный поиск.

Подводные камни

• Частые ошибки. применять только RED и не иметь видимости по ресурсам, из-за чего причина деградации (например, насыщение диска IOPS) остаётся незаметной, хотя пользовательские метрики уже показывают проблему; применять только USE и не видеть пользовательского эффекта — ресурсы могут быть загружены на 95%, но если latency и error rate в норме, это не обязательно требует немедленного действия.