3. 核心指标与黄金信号：延迟、流量、错误、饱和度（USE/RED方法论）
监控系统建好了，数据也进来了。然后呢？
很多团队卡在这一步——指标太多，看不过来。一张大屏上几十个曲线图，告警天天响，但真正出问题时，你反而找不到根因。
我个人习惯，先把指标做减法。不管系统多复杂，核心就四个维度：延迟、流量、错误、饱和度。这就是业界常说的“黄金信号”。再配合 USE 和 RED 方法论，基本能覆盖 90% 的排错场景。
核心观点： 指标不是越多越好。能回答“系统现在健康吗？”的指标，才是好指标。黄金信号就是帮你回答这个问题的。
3.1 延迟（Latency）—— 用户的耐心是有限的
延迟是用户体验最直接的体现。说白了，用户点一下按钮，等多久能看到结果？
我建议把延迟拆成两个维度看：
- 服务端延迟： 从请求到达服务到返回响应的耗时。这是后端优化的主战场。
- 客户端延迟： 用户实际感知到的耗时。包括网络传输、DNS 解析、浏览器渲染等。
我的经验： 曾经有个项目，服务端 P99 延迟只有 50ms，但用户投诉说页面要 3 秒才打开。查了半天，发现是前端加载了 2MB 的 JS 文件。所以，服务端快不等于用户快。
延迟的统计方式也很关键。别只看平均值，那玩意儿会骗人。
| 统计方式 | 含义 | 适用场景 |
|---|---|---|
| 平均值（Avg） | 所有请求耗时的算术平均 | 仅作参考，容易被极端值拉偏 |
| 中位数（P50） | 50% 的请求比这个值快 | 反映大多数用户的体验 |
| P99 | 99% 的请求比这个值快 | 排查长尾问题，SLA 常用指标 |
| P999 | 99.9% 的请求比这个值快 | 高敏感业务，如支付、交易 |
注意： 我曾经见过一个团队，P99 延迟 200ms，看起来很健康。但 P999 高达 5 秒。这意味着每 1000 个请求里就有 1 个用户要等 5 秒。对于电商网站，这 0.1% 的用户可能就是你的大客户。
3.2 流量（Traffic）—— 系统到底在扛多少活？
流量指标回答一个基本问题：系统当前处理的请求量有多大？
我个人习惯用以下几个指标来衡量流量：
- QPS（Queries Per Second）： 每秒查询数。适用于读多写少的系统，比如搜索引擎、缓存。
- RPS（Requests Per Second）： 每秒请求数。更通用的指标，涵盖读写。
- 吞吐量（Throughput）： 单位时间内处理的数据量，比如 MB/s 或 条/秒。
- 并发连接数： 当前正在处理的连接数量。对网关、负载均衡器很重要。
流量指标最大的价值在于：帮你判断流量波动是正常的，还是异常的。
实战案例： 有一次凌晨 3 点，QPS 突然从 1000 飙升到 5000。值班同事以为是攻击，差点封了 IP。我查了一下历史数据，发现是海外用户上班了——那是正常的业务高峰。所以，流量一定要跟历史基线对比，不能只看值。
3.3 错误（Errors）—— 别等用户投诉才发现
错误指标是最直接的“系统出问题了”的信号。但错误也分很多种，不能一概而论。
我通常把错误分成三类：
- 显式错误： HTTP 5xx、4xx，或者业务返回的错误码。这类错误最容易被监控到。
- 隐式错误： 返回了 200，但业务逻辑错了。比如“下单成功”但库存没扣减。这种最坑人。
- 基础设施错误： 连接超时、DNS 解析失败、磁盘 IO 错误。通常由底层组件上报。
我曾经踩过的坑： 有一次线上告警显示错误率 0%，一切正常。但用户疯狂投诉说“订单提交不了”。查了半天，发现是网关返回了 200，但后端服务返回了“系统繁忙”的 JSON 字段。从那以后，我要求所有业务接口必须上报业务错误码，不能只看 HTTP 状态码。
错误率怎么算？我建议用这个公式：
错误率 = (错误请求数 / 总请求数) × 100%阈值怎么设？没有标准答案。我个人习惯：
- 核心交易链路：错误率 > 0.1% 就告警
- 非核心服务：错误率 > 1% 再告警
- 基础设施：任何错误都告警（但要做好聚合，避免告警风暴）
3.4 饱和度（Saturation）—— 系统还能扛多久？
饱和度是四个黄金信号里最容易被忽略的。它回答的是：系统还有多少余量？
说白了，就是你的资源快用完了没。
常见的饱和度指标：
| 资源类型 | 饱和度指标 | 危险信号 |
|---|---|---|
| CPU | CPU 使用率、运行队列长度 | 运行队列 > CPU 核心数 × 2 |
| 内存 | 内存使用率、Swap 使用量 | Swap 持续增长，内存使用率 > 90% |
| 磁盘 | 磁盘使用率、IO 等待时间 | IO 等待 > 30%，磁盘使用率 > 85% |
| 网络 | 带宽使用率、连接队列溢出 | 带宽 > 80%，连接队列丢包 |
| 连接池 | 活跃连接数 / 最大连接数 | 活跃连接 > 80% 最大连接数 |
我的建议： 饱和度指标最好设置多级阈值。比如 CPU 使用率 > 70% 时发个通知，> 85% 时发告警，> 95% 时自动扩容。别等到 100% 了再处理，那时候系统可能已经 hang 住了。
3.5 USE 方法论：从资源视角看问题
USE 方法论是 Brendan Gregg 提出的，全称是 Utilization、Saturation、Errors。它适用于所有资源的监控，比如 CPU、内存、磁盘、网络。
USE 的核心思路很简单：对于每一个资源，问三个问题：
- 利用率（Utilization）： 这个资源有多忙？比如 CPU 使用率 80%。
- 饱和度（Saturation）： 有多少任务在排队？比如 CPU 运行队列长度。
- 错误（Errors）： 有没有出错？比如磁盘 IO 错误。
我为什么喜欢 USE？因为它结构化。你不需要拍脑袋想“该看什么指标”，按 USE 框架走一遍就行。
实战演示： 假设用户反馈“接口响应慢”。按 USE 方法论排查：
- CPU： 利用率 95%，运行队列 8（4 核 CPU）。→ CPU 饱和了。
- 内存： 利用率 60%，无 Swap。→ 内存正常。
- 磁盘： 利用率 30%，IO 等待 5%。→ 磁盘正常。
- 网络： 带宽利用率 20%，无丢包。→ 网络正常。
结论：CPU 是瓶颈。接下来就看是哪个进程在吃 CPU，然后优化代码或扩容。
3.6 RED 方法论：从服务视角看问题
RED 方法论是 Tom Wilkie（Grafana 实验室）提出的，全称是 Rate、Errors、Duration。它适用于服务的监控，比如微服务、API 网关、数据库。
RED 的三个问题：
- 速率（Rate）： 每秒处理多少请求？对应黄金信号的“流量”。
- 错误（Errors）： 失败请求的比例？对应黄金信号的“错误”。
- 耗时（Duration）： 请求处理时间？对应黄金信号的“延迟”。
RED 和 USE 有什么区别？我打个比方：
- USE 是“体检报告”——看你的身体器官（资源）有没有问题。
- RED 是“工作表现”——看你的工作成果（服务）有没有达标。
两者缺一不可。只看 RED，你可能会发现服务慢了，但不知道为什么慢。只看 USE，你可能会发现 CPU 满了，但不知道影响了哪个服务。
我的习惯： 每个微服务至少暴露三个 RED 指标（RPS、错误率、P99 延迟）。每个节点（服务器、容器）至少暴露三个 USE 指标（CPU 利用率、内存利用率、磁盘 IO 等待）。这样无论从上往下查，还是从下往上查，都能快速定位。
3.7 黄金信号 + USE/RED 的落地实践
理论说完了，聊聊怎么落地。我总结了一个四步法：
- 定义指标： 按 USE 和 RED 框架，列出所有需要监控的指标。不要贪多，每个资源/服务 3-5 个指标就够了。
- 设置基线： 收集一周以上的历史数据，确定每个指标的“正常范围”。没有基线，告警阈值就是拍脑袋。
- 配置告警： 按多级阈值设置告警。比如 P99 延迟 > 200ms 发通知，> 500ms 发告警，> 1s 发紧急告警。
- 建立排错流程： 告警触发后，按 USE → RED → 日志 → 链路追踪的顺序排查。不要一上来就看日志，那会淹死你。
避坑指南： 我曾经犯过一个错误——把所有指标都设了告警。结果一天收到 500 条告警，真正的问题反而被淹没了。后来我学乖了：告警要少而精。宁可漏报，不要误报。漏报可以事后复盘，误报会让人麻木。
最后说一句：黄金信号和 USE/RED 方法论不是银弹。它们帮你快速缩小排查范围，但不能替代你对系统的深入理解。工具是死的，人是活的。多花时间了解你的系统，比多配几个监控指标有用得多。