RED 和 USE 方法分别适合什么场景？
简化版
RED 用 Rate、Errors、Duration 观察面向请求的服务；USE 用 Utilization、Saturation、Errors 观察 CPU、磁盘、线程池等资源。RED 先发现用户请求受影响，USE 再定位是否由资源瓶颈导致，两者互补而非二选一。
详细版
RED 为每个入口和关键依赖记录请求率、错误率和延迟分布，按低基数 route/status 分解；USE 为每类资源记录忙碌比例、等待/队列程度和错误。没有明确“资源容量”的对象不宜机械套 USE。
排障从业务 SLO/RED 确认影响时间与范围，再沿依赖进入 USE，结合日志和 Trace 验证原因。利用率低也可能因单核、锁或分片热点而饱和，因此必须同时看 saturation。
完整版教学
一、RED 看服务外部表现
Rate 是单位时间请求数，Errors 是失败请求比例或数量，Duration 用 Histogram 看 P50/P95/P99。它以用户请求为中心，适合 HTTP、RPC 和消息消费处理。
记忆钩子：RED 看“请求过得怎样”，USE 看“资源撑得怎样”。
二、USE 看资源压力
| 字母 | 问题 | 示例 |
|---|---|---|
| U | 忙了多少 | CPU busy、连接占用 |
| S | 等待有多严重 | run queue、线程队列 |
| E | 是否发生错误 | 磁盘错误、分配失败 |
资源错误不能只等应用 500 才发现，例如磁盘重试可能先表现为延迟。
三、为什么 Utilization 不够
机器平均 CPU 40%，但单核 100% 的串行线程已成瓶颈；磁盘带宽未满，IO 队列却因尾延迟堆积。聚合利用率会掩盖局部热点，saturation 能显示需求超过即时服务能力。
utilization = busy_time / elapsed_time
saturation = queued_or_waiting_work四、RED 数字示例
服务 1000 RPS、错误率从 0.1% 升到 2%，意味着失败由 1/s 增至 20/s；同时 P99 从 200ms 到 2s，说明不仅失败增多，成功请求也受拖累。
错误要按业务与技术分类，用户参数错误不应全部计入服务端 SLI，但仍可单独观测。
五、联合排障流程
先在 RED 确认 /checkout 从 10:05 开始 P99 上升，再看 Trace 指向数据库等待，最后用 USE 发现连接池饱和和队列增长。顺序避免一上来就在数百个资源图里猜原因。
如果 RED 异常而 USE 正常，应继续检查依赖、锁竞争、发布和数据热点，而不是强行归因为机器不足。
六、消息与批处理如何套用
消息系统的 Rate 可用处理率，Errors 用失败/死信，Duration 用处理耗时和端到端 lag；Broker 资源再用 USE。批处理还需完成率、截止时间和积压年龄，不能只看 QPS。
方法是提问框架，不是固定指标模板，应按系统语义补充。
对自动伸缩系统还要同时观察需求和容量变化；利用率下降可能只是扩容生效，不代表请求异常已恢复。
无服务器平台缺少主机指标时，可用并发额度、节流、冷启动和队列等待替代传统 CPU USE 视角。
RED 与 USE 的看板应共享时间和发布标记，避免在不同时区或窗口里错误关联。
七、常见误区与追问
- 误区：RED 和 USE 只能选一个。 它们分别观察服务与资源。
- 误区：CPU 低说明没有资源瓶颈。 单核、连接池或锁可能已饱和。
- 误区：Duration 看平均值即可。 平均会掩盖长尾。
- 误区：所有 4xx 都算服务错误。 SLI 要按责任边界分类。
- 追问：先看哪套？ 通常先用户影响/RED，再沿依赖查 USE。
- 追问：队列长度属于什么？ 是典型 saturation 信号，还需结合到达与处理率。
- 追问：数据库怎么应用？ 请求层用 RED，连接、CPU、IO 用 USE。
八、加强记忆
RED 用流量、错误、时延描述服务体验，USE 用利用率、饱和度、资源错误解释容量状态。排障先确认用户影响，再沿 Trace 到资源；同时警惕平均值和聚合值掩盖长尾、单核与热点，按消息或批处理语义补充 lag 和截止时间。