核心指标与黄金信号：四大黄金信号（延迟、流量、错误、饱和度）及USE/RED方法论

大家好，我是你们的老朋友。今天我们来聊聊监控里最核心的东西——指标。

说实话，我见过太多团队一上来就堆监控，什么CPU、内存、磁盘IO，铺了一屏幕，结果线上出问题的时候，盯着大盘完全不知道看哪里。说白了，你收集了一堆数据，但没有抓住关键信号。

那什么是关键信号？业界有两个非常成熟的方法论：四大黄金信号和USE/RED。今天我就把这两个东西揉碎了讲给你听。

一、四大黄金信号：Google SRE 的看家本领

Google 的 SRE 团队总结过，无论你的系统多复杂，最终只需要关注四个维度：延迟、流量、错误、饱和度。我习惯叫它们「黄金四角」。

核心观点： 这四个信号覆盖了用户视角和系统视角。缺一个，你的监控就是瘸腿的。

1. 延迟（Latency）

延迟就是请求从发出到收到响应的时间。嗯，这里要注意，延迟分两种：

  • 服务端延迟：你的应用处理请求花了多久。
  • 客户端延迟：用户感知到的总耗时，包括网络传输、排队等。

我个人习惯把重点放在高百分位延迟上，比如 P99、P95。为什么？因为平均值会骗人。我曾经遇到过一个接口，平均延迟 50ms，看起来很美。但一查 P99，好家伙，直接飙到 5 秒。那 1% 的用户体验极差，但平均值把它掩盖了。

避坑指南： 监控延迟时，一定要区分「成功请求」和「失败请求」的延迟。失败的请求往往返回得特别快（比如 4xx 错误），如果把它们混在一起算，你的 P99 会异常好看，但实际体验一塌糊涂。

2. 流量（Traffic）

流量就是系统承载的请求量。对于 Web 服务，通常是 QPS（每秒查询数）或 RPS（每秒请求数）。对于数据库，可能是 TPS（每秒事务数）。

流量本身不是问题，但流量突变往往是问题的前兆。我记得有一次，凌晨三点流量突然涨了 10 倍，我第一反应是「被攻击了？」。后来发现是运营搞了个秒杀活动，没通知我们。你想想看，如果没有流量监控，你连系统为什么挂都不知道。

3. 错误（Errors）

错误分显式和隐式：

  • 显式错误：HTTP 5xx、4xx，或者业务返回的错误码。
  • 隐式错误：返回了 200，但业务逻辑错了。比如返回了空数据、或者返回了错误的结果。

我建议把错误率拆成两个指标：HTTP 错误率和业务错误率。为什么？因为 HTTP 5xx 只占一小部分，很多错误是业务层面的。比如支付接口返回了 200，但 body 里写着「余额不足」。这种错误，你的基础监控根本抓不到。

4. 饱和度（Saturation）

饱和度衡量的是系统资源被「填满」的程度。说白了，就是你的系统还有多少余量。

常见的饱和度指标：

  • CPU 使用率（但要注意，CPU 100% 不一定代表饱和，要看是否在排队）
  • 内存使用率
  • 磁盘 I/O 等待时间
  • 网络带宽使用率
  • 连接池、线程池的排队长度

这里有个坑：CPU 使用率 90% 不代表饱和，但如果 CPU 的运行队列长度持续大于 CPU 核心数，那才是真的饱和了。我曾经踩过这个坑，CPU 显示 95%，但系统响应很慢，后来发现是运行队列排了 200 个任务在等。

二、USE 方法论：资源视角的监控利器

USE 是 Brendan Gregg 提出的，全称是 Utilization、Saturation、Errors。它专门用来分析资源的健康状况。

你想想看，一个系统里有哪些资源？CPU、内存、磁盘、网络、连接池、线程池……USE 方法论就是针对每个资源，问三个问题：

资源 利用率（Utilization） 饱和度（Saturation） 错误（Errors）
CPU CPU 使用率 运行队列长度 硬件错误、中断丢失
内存 内存使用率 Swap 使用量、OOM 次数 内存分配失败
磁盘 磁盘 I/O 使用率 I/O 等待队列长度 磁盘坏道、I/O 错误
网络 带宽使用率 丢包率、重传率 网络接口错误

我个人习惯用 USE 来做根因分析。比如系统变慢了，我会先看 CPU 利用率高不高？不高。再看运行队列长不长？长。那说明 CPU 在排队，但利用率不高，可能是锁竞争或者上下文切换太多。你看，三步就能定位到方向。

注意： USE 方法论只适用于资源，不适用于服务本身。比如你不能用 USE 去分析一个 API 的延迟，那是 RED 方法论的事。

三、RED 方法论：服务视角的监控利器

RED 是 Tom Wilkie 提出的，全称是 Rate、Errors、Duration。它专门用来分析服务的健康状况。

说白了，RED 就是四大黄金信号的简化版：

  • Rate：流量（每秒请求数）
  • Errors：错误（错误数或错误率）
  • Duration：延迟（请求耗时分布）

为什么没有饱和度？因为饱和度是资源维度的，服务本身没有「饱和度」这个概念。服务的饱和度其实是底层资源的饱和度。

我建议每个微服务都暴露这三个指标：

# 示例：Prometheus 指标定义
# 请求总数（用于计算 Rate）
http_requests_total{service="user-service", method="GET", endpoint="/users"}

# 错误请求数（用于计算 Errors）
http_requests_errors_total{service="user-service", method="GET", endpoint="/users", error_code="500"}

# 请求耗时分布（用于计算 Duration）
http_request_duration_seconds{service="user-service", method="GET", endpoint="/users"}

有了这三个指标，你就能回答三个核心问题：

  1. 服务在承受多大的流量？
  2. 服务有没有在报错？
  3. 服务响应快不快？

四、黄金信号 + USE + RED：如何组合使用？

你可能会问，这三个方法论到底怎么选？我的建议是：

  • 用户视角：用四大黄金信号（延迟、流量、错误、饱和度）做全局大盘。
  • 服务视角：用 RED 方法论监控每个微服务的健康状况。
  • 资源视角：用 USE 方法论监控底层基础设施。

举个例子，线上出问题了，我会先看黄金信号大盘：延迟飙高、错误率上升。然后点进具体的服务，看 RED 指标：哪个接口的延迟高？哪个接口的错误多？最后看 USE 指标：是不是 CPU 饱和了？是不是磁盘 I/O 满了？

这样一层层剥下去，定位问题的速度会快很多。我曾经用这个思路，在 5 分钟内定位到一个数据库连接池耗尽的问题——先看到延迟飙升，再看服务 RED 发现数据库调用超时，最后看 USE 发现连接池利用率 100%，队列长度持续增长。

小技巧： 不要试图把所有指标都放在一个面板上。我习惯建三个面板：

  • 业务面板：黄金信号 + 业务指标
  • 服务面板：RED 指标 + 依赖调用
  • 资源面板：USE 指标 + 基础设施

这样不同角色的人看不同的面板，不会信息过载。

五、总结

好了，今天的内容就到这里。我们来回顾一下：

  • 四大黄金信号：延迟、流量、错误、饱和度。这是监控的顶层框架。
  • USE 方法论：利用率、饱和度、错误。用来分析资源。
  • RED 方法论：速率、错误、延迟。用来分析服务。

记住，监控不是为了收集数据，而是为了在出问题时能快速定位。抓住这几个核心信号，你的监控体系就有了骨架。

下一章，我会讲如何把这些指标落地到 Prometheus 和 Grafana 中，包括具体的告警规则怎么写。到时候见。

← 上一章 📖 返回目录 下一章 →