3. Metric设计原则：USE方法与RED方法在服务监控中的应用
在可观测性工程中，Metric（指标）是故障发现、定位与复盘的基础数据源。设计不当的指标集会导致“数据丰富、信息贫乏”的困境。本章深入剖析业界最成熟的两套方法论——USE方法（资源视角）与RED方法（服务视角），并给出它们在微服务与基础设施监控中的具体落地模式。
3.1 USE方法：资源维度的黄金三角
USE方法由Brendan Gregg提出，适用于任何物理或虚拟资源（CPU、内存、磁盘、网络、连接池、线程池）。其核心是回答三个问题：
| 维度 | 英文 | 定义 | 典型示例 |
|---|---|---|---|
| 利用率 | Utilization | 资源被服务占用的时间比例或容量比例 | CPU使用率、内存占用率、磁盘IOPS利用率 |
| 饱和度 | Saturation | 资源无法及时服务的额外排队或等待程度 | CPU运行队列长度、磁盘IO等待队列、内存swap使用量 |
| 错误率 | Errors | 资源操作中发生的错误计数或比例 | 磁盘读写错误、网络丢包、内存ECC错误 |
实践要点：USE方法强调“先利用率，再饱和度，最后错误率”。利用率超过80%时需关注饱和度指标；饱和度持续上升往往是故障的前兆，比利用率更早暴露风险。
3.2 RED方法：服务维度的黄金三角
RED方法由Tom Wilkie（Grafana Labs）提出，专为微服务与API设计，聚焦用户体验：
| 维度 | 英文 | 定义 | 典型示例 |
|---|---|---|---|
| 速率 | Rate | 单位时间内的请求量（吞吐量） | requests/sec、rps、qps |
| 错误 | Errors | 请求失败的计数或比例 | HTTP 5xx计数、错误率百分比 |
| 持续时间 | Duration | 请求处理耗时分布 | P50/P90/P99延迟、平均延迟 |
常见误区：RED方法中的“错误”不仅包括HTTP 5xx，还应包含业务逻辑错误（如订单创建失败返回200但body含error_code）。建议使用“有效请求率”而非单纯的状态码过滤。
3.3 USE与RED的对比与协同
两种方法并非互斥，而是分别覆盖资源层与服务层。在故障定位中，通常需要联合使用：
- RED方法负责“服务是否正常”——从用户视角感知故障。
- USE方法负责“资源是否瓶颈”——从系统视角定位根因。
例如：当RED显示P99延迟飙升时，USE可以快速排查CPU饱和度、磁盘IO等待队列或网络丢包。
推荐组合策略：每个微服务至少暴露RED三指标（速率、错误、持续时间）；每个节点/容器至少暴露USE三指标（利用率、饱和度、错误率）。两者结合形成“服务→资源”的完整监控链路。
3.4 两种方法在服务监控中的融合架构
下图展示了在典型微服务拓扑中，USE与RED如何分层部署并协同工作：
3.5 指标设计落地清单
在实际项目中，建议按以下清单为每个服务与资源建立指标基线：
| 监控对象 | 方法 | 必须指标 | 推荐指标 |
|---|---|---|---|
| HTTP API / gRPC | RED | 请求速率、错误率、P50/P99延迟 | P90延迟、慢请求计数、有效请求率 |
| 数据库实例 | USE | CPU利用率、连接数饱和度、慢查询错误 | IOPS利用率、复制延迟、锁等待饱和度 |
| 消息队列 | USE + RED | 生产速率、消费速率、队列深度（饱和度） | 消费延迟、重试错误率、积压增长率 |
| 容器 / 节点 | USE | CPU利用率、内存利用率、磁盘IO饱和度 | 网络丢包率、OOM错误计数、文件描述符利用率 |
| 缓存（Redis/Memcached） | USE + RED | 命中率、操作速率、内存利用率 | 逐出率、连接饱和度、命令错误率 |
3.6 故障特征提取：从指标到模式
USE与RED指标不仅是监控面板上的数字，更是故障特征提取的原材料。常见故障模式与指标特征对应关系如下：
- 资源瓶颈型故障：USE饱和度持续上升 → RED延迟飙升 → 错误率在饱和度达到阈值后陡增。
- 代码缺陷型故障：RED错误率突然升高（如HTTP 500）→ USE指标正常 → 需结合日志与链路追踪。
- 容量不足型故障：RED速率正常或下降 → USE利用率接近100% → 饱和度队列无限增长。
- 依赖故障型故障：下游服务USE饱和度异常 → 上游RED错误率/延迟连锁上升。
MTTR复盘口径建议：在故障复盘时，将RED指标的变化时间点作为“故障发现时间”，将USE指标异常的时间点作为“根因定位时间”。两者之间的差值，就是指标设计是否合理的直接度量——差值越小，说明指标覆盖越精准。
3.7 两种方法的指标聚合与告警策略
下图展示了基于USE与RED的告警分层设计，避免告警风暴并提升根因定位效率：
3.8 小结
USE方法与RED方法共同构成了现代服务监控的双支柱：
- USE 回答“资源是否健康”——是基础设施与中间件的监控基石。
- RED 回答“服务是否正常”——是用户体验与SLO的直接度量。
- 两者结合，形成从用户请求→服务处理→资源消耗的完整可观测链路，是故障特征提取与MTTR复盘的核心数据基础。
下一步实践建议：对照本章的落地清单，检查你当前负责的服务是否同时覆盖了RED与USE指标。缺失任何一个维度，都意味着故障定位链路存在盲区。