黄金信号 / RED / USE：三套指标体系怎么选

更新时间：2026-09-19。新手最容易问的问题：监控那么多指标，到底先看哪些？业界沉淀了三套互补的方法论——Google 的四大黄金信号、Weaveworks 的 RED、Brendan Gregg 的 USE。它们不是三选一，而是分别站在「服务请求」和「系统资源」两个视角。

一、三套方法各看什么

1）Google 四大黄金信号（Golden Signals）——面向服务

信号	含义	典型指标
延迟 Latency	请求耗时，要区分成功/失败请求，看分位数	P95/P99 响应时间
流量 Traffic	负载压力	QPS、TPS、在线连接数
错误 Errors	失败率	5xx 比例、超时率、业务错误码
饱和度 Saturation	离容量上限还有多远	CPU、内存、队列长度、事件循环积压

2）RED 方法——面向请求驱动的服务（微服务/API/Web）

• Rate：每秒请求数
• Errors：每秒失败请求数 / 错误率
• Duration：请求耗时分布

RED 其实是黄金信号里前三个（流量/错误/延迟）的精炼，故意不含饱和度，因为对应用层服务来说，容量往往由底层资源决定，开发者更该先盯住「我的服务在多快地、以多高成功率处理请求」。它和 gRPC 拦截器统一埋点（method+code+延迟直方图）天然契合。

3）USE 方法——面向资源/组件（CPU、磁盘、网卡、队列）

对每一种资源检查三件事：

• Utilization：利用率（忙碌时间占比，如 CPU 80%）
• Saturation：饱和程度（排队/积压，如 run queue、IO wait、连接队列）
• Errors：错误计数（丢包、ECC 错误、坏块、重传）

USE 的精髓是即使没有明显瓶颈也要主动找错误和饱和：磁盘利用率低但 IO 排队高、网卡没满但丢包在涨，这些「使用率不高却已经病了」的情况，光看利用率发现不了。

二、怎么选：请求用 RED，资源用 USE，黄金信号兜底

你在监控什么？
├─ 一个对外提供请求的服务（HTTP/gRPC/DB 查询）
│    → RED：Rate / Errors / Duration（最直接，告警优先配这三个）
├─ 一台机器 / 一块磁盘 / 一张网卡 / 一个队列（资源组件）
│    → USE：Utilization / Saturation / Errors
└─ 想要一套覆盖端到端的通用清单
     → 四大黄金信号（在 RED 基础上补 Saturation）

实践中三者是嵌套的：服务 RED 报警（P99 飙高、错误率上涨）后，下钻到该实例的资源 USE（是不是某个核软中断打满、磁盘饱和、网卡丢包），定位到瓶颈再用 perf、mpstat、iostat 深挖。

三、一个服务的组合落地示例

层次	方法	具体指标	工具
网关/服务	RED	QPS、5xx 率、P99	Prometheus + Grafana
JVM/Go 运行时	USE（套资源）	堆使用率、GC 停顿（饱和）、OOM/Full GC（错误）	jstat、micrometer
主机 CPU	USE	%util、run queue 长度、上下文切换	vmstat、runqlat
磁盘	USE	%util、await 队列、I/O 错误	iostat、biolatency
网卡	USE	带宽利用率、send/receive 队列、丢包/重传	ss、dropwatch

为什么延迟必须看分布而不是平均值，见分位数直方图；这些指标如何转成承诺目标，见SLI/SLO 定义。

坑

• 只看利用率不看饱和/错误：CPU 40% 但单核软中断打满、磁盘没满但丢包，USE 的 S/E 才暴露问题。
• 延迟只看平均值：必须看 P95/P99 分布，否则长尾被均值掩盖。
• 对应用层服务硬套 USE：「这个微服务的利用率是多少」没有自然答案，请求服务用 RED 更顺手。
• RED 的 Errors 只数 5xx：业务失败（库存不足、支付被拒）也要按 code 维度统计。
• 黄金信号不区分成功/失败延迟：失败请求常常快速返回错误，混在一起会低估正常请求的真实延迟。

总结

四大黄金信号是延迟、流量、错误、饱和度的通用兜底，RED 抽出请求率/错误数/耗时三项专盯对外请求服务，USE 用利用率/饱和度/错误主动体检 CPU、磁盘、网卡等资源组件；落地时先用 RED 发现服务变慢或出错，再沿调用链下钻到对应资源用 USE 找排队和丢包，最后用 perf、iostat 等工具定位根因，三者嵌套而非互斥。