“该监控哪些指标？"——回答不了这个问题，监控仪表盘就会沦为"什么都有、什么都没用"的数字墙。方法论给出答案：Google 用四大黄金信号看用户视角的服务健康，RED 把服务指标压缩为三个数字，USE 从资源视角看"设备是否饱和”。本指南讲透这三套指标设计方法论，以及如何组合落地到业务监控与资源监控。
关键概念：黄金信号（服务健康）＝延迟/流量/错误/饱和度；RED（服务）＝Rate/Errors/Duration；USE（资源）＝Utilization/Saturation/Errors。三套方法论解决的是同一问题：用最少的指标看清"服务到底行不行"。
1. 为什么需要指标方法论
1.1 没有方法的监控会怎样
典型失控表现：
- 每个服务 40+ 指标，告警天天响、没人看
- 指标都"绿"，但用户已经报障（指标没选对）
- 资源指标满屏，却不知道"哪个先扛不住"
问题本质：
指标数量 ≠ 可观测性
→ 需要"选什么、怎么定义、怎么解读"的方法
1.2 方法论的共同目标
一套好指标应做到：
- 最少数量覆盖核心风险（别求全）
- 从"用户/服务/资源"视角定义健康
- 指标与告警、容量规划、SLO 直接连通
- 可解释：新同学看指标能判断服务是否正常
2. Google 四大黄金信号
2.1 四个信号
Latency（延迟）：请求多快返回
· 关注分布（P50/P95/P99）而非均值
· 区分"成功请求"与"失败请求"的延迟
· 错误请求延迟高≠问题，可能是正常失败路径慢
Traffic（流量）：请求压力有多大
· QPS/RPS、并发请求、带宽/吞吐
· 高流量本身不是问题，结合延迟/错误判断
Errors（错误）：请求失败的比率与原因
· 显式错误：HTTP 5xx、异常返回码
· 隐式错误：返回 200 但结果不对（更难发现）
Saturation（饱和度）：服务还有多少余量
· 接近瓶颈的程度（如 CPU 队列、连接池占用、线程池队列）
· 饱和度越接近 100%，延迟越会非线性恶化
2.2 如何落地黄金信号
每个服务至少建立四个信号面板：
延迟：histogram，P50/P95/P99 + 告警
流量：QPS 总量 + 按路由/租户拆
错误：错误率（error rate）而非错误数
饱和度：CPU/内存/连接池/队列利用率
组合解读示例：
流量 ↑ + 延迟 ↑ + 错误 ↑ → 容量/资源问题
流量 ↓ + 延迟 ↑ + 错误 ↑ → 依赖故障（下游慢）
流量正常 + 错误 ↑ → 逻辑/数据问题
ℹ️ 核心：黄金信号的价值是"用四个维度交叉判断根因方向"。单看任一维度都会误诊——四个一起看才有诊断力。
3. RED：服务的三个数字
3.1 RED 方法
RED = 每个服务只维护三个指标：
Rate（速率） ：每秒请求数（QPS）
Errors（错误） ：每秒错误数 / 错误率
Duration（时长）：请求耗时分布（P95/P99）
用途：
主要针对"请求/响应"型服务（API/后端/网关）
与黄金信号重叠度很高，但更"最小化"
→ 适合作为每个微服务的基础监控基线
3.2 RED 落地示例
以 Prometheus 为例的三个指标：
http_requests_total → Rate
http_requests_total{code=5xx} → Errors
http_request_duration_seconds_histogram → Duration
面板与告警：
Rate：请求量趋势（业务流量）
Errors：错误率 > 阈值 → 告警
Duration：P95 > 阈值 → 告警
扩展：
RED 适合"每个服务一套"统一基线
再叠加业务指标（订单数、转化率）做业务观测
4. USE：资源的三个维度
4.1 USE 方法
USE = 面向"资源"（CPU/内存/磁盘/网络/连接）的三问：
Utilization（利用率）：资源有多忙？
读-改-写占比、CPU 使用率、磁盘 IO 利用率
Saturation（饱和度）：有多少排队/等待？
运行队列长度、等待数、拥塞程度
Errors（错误）：有多少错误？
设备错误、丢包、超时、IO 错误
用途：
面向资源/基础设施的监控（服务器、数据库、队列、网络）
定位"资源是否成为瓶颈"比黄金信号更精准
4.2 USE 落地示例
CPU：
Utilization：% CPU 使用率
Saturation：load average / run queue
Errors：CPU 硬件错误（罕见）
磁盘：
Utilization：磁盘使用率 / IO 利用率
Saturation：IO 等待队列（iowait）
Errors：坏块/超时
网络：
Utilization：带宽利用率
Saturation：发送/接收队列、丢包
Errors：网卡错误计数
数据库连接池：
Utilization：已用连接/总数
Saturation：等待获取连接的请求数
Errors：连接超时/拒绝
ℹ️ 核心：USE 的关键是"Saturation（排队）"——资源接近饱和的早期信号比利用率更早。利用率 90% 可能还不堵，一旦开始排队，延迟立刻恶化。
5. 三套方法论如何选择与组合
5.1 适用对照
黄金信号（Google）：
· 全局服务健康，架构师/值班第一屏
· 强调"延迟分布 + 饱和度"的诊断组合
RED：
· 每个服务的最小监控基线
· 适合大规模微服务：统一三个指标，低成本全覆盖
USE：
· 基础设施/资源视角，容量规划
· 解决"资源是不是瓶颈、还有多少余量"
组合建议：
服务层用 RED（统一基线）
业务层用黄金信号（诊断 + 用户视角）
资源层用 USE（容量 + 瓶颈定位）
三套是"同一系统在不同视角"的观测，互补而非冲突
5.2 一个综合落地示例
订单服务（示例）：
服务 RED：
order_requests_total / order_errors_total / order_duration_seconds
业务黄金信号：
latency P99、QPS、错误率、饱和度（DB 连接池利用率）
依赖资源 USE：
数据库 CPU 利用率 + IO 队列、Redis 连接饱和度
→ 告警、容量规划、SLO 都基于这套指标
避免：
- 每个服务 30+ 自定义指标（用统一基线 + 少量业务扩展）
- 指标口径不一致（命名/单位/聚合方式要统一）
6. 与 SLO / 告警 / 容量规划的衔接
6.1 指标 → SLO
SLO 的指标来源就是方法论指标：
SLI 可用性 = 1 - Errors/Rate
SLI 延迟 = P95 latency 或 成功请求比例
→ 用黄金信号/RED 的指标直接定义 SLI
好处：
指标定义与 SLO 定义同源 → 无口径冲突
6.2 指标 → 告警
告警规则设计原则（基于方法论）：
- 错误率告警：Errors/Rate 超阈值（而非错误数）
- 延迟告警：P95/P99 超阈值（而非均值）
- 饱和度告警：接近阈值前提前告警（容量前置）
- 组合告警：延迟高 + 错误高 + 流量异常 → 一次到位
避免：
- 直接对"利用率 100%"告警（已经晚了）
- 对均值告警（掩盖长尾用户受害）
6.3 指标 → 容量规划
用指标做容量：
- 记录峰值 Rate/饱和度 → 预测扩容点
- 饱和度趋势（运行队列增长）→ 提前扩容
- 黄金信号 + USE 结合：服务变慢先看资源饱和度
关键：
容量规划看"Saturation 趋势"而非"Utilization 当前值"
排队出现时，已经是容量临界
7. 常见避坑
| 坑 | 现象 | 对策 |
|---|---|---|
| 指标多而杂 | 没人看、没价值 | 方法论选最小集 |
| 只看均值 | 长尾用户受害 | 用 P95/P99 分布 |
| 只报错误数 | 流量不同难比较 | 用错误率（Errors/Rate） |
| 忽略饱和度 | 延迟突增才发现 | 监控排队/队列 |
| 每服务自定义一堆 | 口径不统一 | 统一基线 + 少量扩展 |
| 告警只看单指标 | 误诊根因 | 黄金信号组合解读 |
8. 最佳实践清单
□ 每个服务建 RED 三指标（Rate/Errors/Duration）基线
□ 业务关键服务叠加黄金信号（延迟分布/流量/错误率/饱和度）
□ 基础设施用 USE（利用率/饱和度/错误）做容量监控
□ 延迟一律用分布（P50/P95/P99），告警用 P95/P99
□ 错误用错误率而非错误数，区分显式/隐式错误
□ 饱和度是容量预警的前置信号，提前告警
□ 指标口径统一（命名/单位/聚合），与 SLO 同源
□ 面板按"服务/资源"组织，第一屏能回答"行不行"
一句话原则
黄金信号看健康、RED 建基线、USE 查资源，
三套方法论用最少的指标，回答"服务到底行不行"。
小结
监控指标方法论的核心是"用最少的指标回答服务健康"：黄金信号从用户视角看延迟/流量/错误/饱和度，RED 为每个服务建立 Rate/Errors/Duration 最小基线，USE 从资源视角定位利用率/饱和度/错误。落地记住五件事：服务层用 RED 统一基线、业务层用黄金信号做诊断、资源层用 USE 管容量、延迟看分布告警用 P95/P99、错误用错误率。当团队每个人都用同一套语言解读指标，监控就不再是"数字墙"，而是"一眼可知服务是否正常、瓶颈在哪、还差多少容量"的共同判断力。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。