RED 与 USE 指标：监控与可观测性的两大方法论
RED（速率/错误/耗时）面向服务与用户体验，USE（利用率/饱和度/错误）面向资源与基础设施。两套方法论如何互补、各自的 Prometheus 实现与仪表盘组织方式，一篇讲清。
现代系统组件众多、交互复杂，"什么都监控"等于什么都看不清。RED 和 USE 是两个久经考验的指标组织框架：RED 从用户体验视角看服务，USE 从资源视角看基础设施。两者互补——RED 告诉你"用户正在受苦"，USE 告诉你"病根在哪个资源"。
两套方法论的分工
| RED | USE | |
|---|---|---|
| 全称 | Rate, Errors, Duration | Utilization, Saturation, Errors |
| 视角 | 服务/用户体验 | 资源/基础设施 |
| 回答 | 用户现在体验如何？ | 底层资源健康吗？ |
| 适用对象 | 每个服务、接口 | 每台主机、每个资源（CPU/磁盘/网卡） |
| 提出者 | Tom Wilkie（Grafana） | Brendan Gregg（性能分析大神） |
典型联动场景：RED 指标显示响应时间飙升 → 翻 USE 指标发现数据库服务器 CPU 饱和度 98% → 根因方向直接锁定。
RED 方法详解
由 Grafana Labs 的 Tom Wilkie 推广，对每个服务采集三个指标：
1. Rate（速率）
单位时间处理的请求数。Web 服务是 HTTP 请求/秒，数据库是查询/秒，消息队列是消息/秒。速率是流量的直接度量，也是其他两个指标的分母。
# HTTP 请求速率（按服务分组）
sum by (service) (rate(http_requests_total[5m]))
2. Errors（错误）
失败请求的速率或占比。注意定义清楚什么算"失败"：HTTP 5xx 肯定算，4xx 通常算客户端问题（但也要看比例突变），业务层失败（如支付失败）视情况纳入。
# 错误率（百分比）
sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))
/
sum by (service) (rate(http_requests_total[5m])) * 100
3. Duration（耗时分布）
请求处理时间的分布，不是平均值。平均值会掩盖长尾——平均 50ms 的接口可能有 5% 的请求超过 3 秒。用直方图（Histogram）统计，看 P50/P90/P99 分位：
# P99 延迟
histogram_quantile(0.99,
sum by (service, le) (rate(http_request_duration_seconds_bucket[5m])))
USE 方法详解
Brendan Gregg 为每个资源（CPU、内存、磁盘、网卡）提出三个检查项：
1. Utilization（利用率）
资源有多忙。CPU 的使用率百分比、磁盘的繁忙时间占比、内存的占用比例。100% 利用率意味着资源满负荷。
# CPU 利用率
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
2. Saturation（饱和度）
资源排队等活的程度——这是比利用率更早的预警信号。CPU 的负载队列（load average）、磁盘的 IO 等待、内存的 swap 换页。利用率 100% 时你已经晚了，饱和度升高时还有时间。
# 磁盘 IO 饱和度（等待队列）
rate(node_disk_io_time_weighted_seconds_total[5m])
3. Errors（错误）
资源层面的错误事件：网卡丢包、磁盘坏块、内存 ECC 错误、TCP 重传。这类错误往往是硬件老化或链路问题的早期信号。
# 网卡丢包
rate(node_network_receive_drop_total[5m])
用两个框架组织仪表盘
RED 仪表盘（每个服务一页）：顶部三个核心图——请求速率、错误率、延迟分位；下面按接口/端点下钻。值班时第一眼看的就是它。
USE 仪表盘（每个资源一层）：主机视图——CPU/内存/磁盘/网络的利用率+饱和度；数据库视图——连接数、查询速率、锁等待；容器视图——CPU/内存相对 limit 的占比。
排障动线：用户投诉 → RED 仪表盘确认影响面 → USE 仪表盘定位资源瓶颈 → 日志/Trace 找具体原因。
观测云对照
观测云让两套方法论开箱即用：主机/容器/数据库的 USE 指标由 DataKit 自动采集，内置视图直接呈现利用率与饱和度；服务的 RED 指标通过 APM 探针自动埋点，请求速率、错误率、P99 延迟无需手写一行 PromQL；两者在同一场景仪表盘里联动，从"用户侧症状"到"资源侧根因"两次点击完成下钻。告警也可以直接按 RED/USE 语义配置——错误率告警用阈值检测，饱和度趋势用区间预测。
常见问题（FAQ）
Q：RED 和四大黄金信号是什么关系？
A：高度重叠。黄金信号的延迟、流量、错误对应 RED 三项；黄金信号多了一个"饱和度"（借自 USE）。实务上用哪套都行，关键是覆盖"用户体验 + 资源容量"两个视角。
Q：该给批处理任务（非请求型服务）用 RED 吗？
A：RED 是请求驱动模型，批任务要变通：Rate=处理条目/秒，Errors=失败条目，Duration=单批次耗时。思想不变，量纲换掉。
Q：所有资源都要上 USE 吗？会不会太多？
A：先覆盖请求关键路径上的资源：应用服务器 CPU/内存、数据库、缓存、带宽。边缘资源出问题时会通过关键路径的指标间接显现。
