# 四大黄金信号 · 以及三套方法论的关系

> Google SRE 的 Latency、Traffic、Errors、Saturation。这一章讲清它和 RED/USE 的关系（它其实是 RED + 饱和度）、它独有的两个洞见——「成功请求和失败请求的延迟要分开看」以及「饱和度要看趋势和预测」。

- 作者：David（道雾轩）
- 专栏：指标采集与观测（https://daiw.org/manual/observability.md）
- 最后更新：2026-07-15
- 原文：https://daiw.org/manual/observability/four-golden-signals
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 四大黄金信号 · 以及三套方法论的关系

第三套方法论来自 Google 的《SRE Book》——**四大黄金信号**（Four Golden Signals）。书里的说法很硬气：**如果你只能测四个指标，就测这四个**。

| 信号 | 含义 |
| --- | --- |
| **Latency** | 请求耗时 |
| **Traffic** | 流量（请求速率） |
| **Errors** | 错误率 |
| **Saturation** | 饱和度：系统“有多满” |

## 它和 RED/USE 是什么关系

<Callout type="info">
  **一眼就能看出来：黄金信号 ≈ [RED](https://daiw.org/manual/observability/red-method) + [饱和度](https://daiw.org/manual/observability/use-method)。**

  | 黄金信号 | 对应 |
  | --- | --- |
  | Latency | = RED 的 **D**uration |
  | Traffic | = RED 的 **R**ate |
  | Errors | = RED 的 **E**rrors |
  | **Saturation** | = USE 的 **S**aturation ← **多出来的这个** |

  所以三套方法论的关系是：

  - **RED** 从**服务/请求**视角出发，给出三个信号。
  - **USE** 从**资源**视角出发，给出三个信号。
  - **黄金信号**从**面向用户的整体系统**视角出发，**把 RED 的三个 + USE 里最重要的那个（饱和度）合在一起**。

  **它们不矛盾，是同一片领土的三张地图。** 实践中你不需要“三选一”，而是：**对服务用 RED、对资源用 USE，而黄金信号提醒你：别忘了饱和度也是面向用户的一等信号。**
</Callout>

## 为什么 Google 要把饱和度提到服务层

这是黄金信号最有价值的地方——它把“饱和度”从**资源指标**提升成了**服务级的一等信号**：

<Callout type="info">
  **因为饱和度是**唯一有预测性**的信号。** 其他三个都是**滞后**的：

  - Latency 涨了 → **已经**慢了，用户**已经**在受苦。
  - Errors 涨了 → **已经**错了，用户**已经**看到 500 了。
  - Traffic 变了 → 那是**外部输入**，不是你的健康。

  **只有饱和度是“提前量”**：线程池用了 80%、磁盘还剩 20%、连接池快满了——这些时候**用户还什么都没感觉到**，但你知道**再涨一点就要出事**。

  **这就是“叫醒你”和“叫醒你时已经晚了”的区别。** 基于 Latency/Errors 的告警本质上是**事后**通知（SLO 已经在燃烧了）；基于饱和度的告警是**事前**预警，你还有时间扩容。

  《SRE Book》强调饱和度要看“**趋势和预测**”，而不只是当前值：
  ```text
  # 不只问"磁盘满了吗",要问"按这个速度,多久会满"
  # predict_linear:基于过去 6 小时趋势,预测 4 小时后的值
  predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*3600) < 0
  ```
  这条查询的意思是：“**按当前增长速度，4 小时内磁盘会满**”——它在磁盘还有 30% 空间时就告警，给你充足的处理时间。**这比“磁盘使用率 > 90%”这种静态阈值高明得多**：后者在小盘上太晚（90% 时可能只剩几分钟），在大盘上太早（90% 的 10TB 盘还剩 1TB，能撑一周）。[第 5 部分讲阈值](https://daiw.org/manual/observability/alert-thresholds)时会展开这个思路。
</Callout>

## 黄金信号独有的洞见：成功和失败的延迟要分开

《SRE Book》里有个容易被忽略、但极其实用的提醒：

<Callout type="warn">
  **失败请求的延迟会污染你的延迟指标——必须把成功和失败分开统计。**

  两种污染方向，都很致命：

  - **失败**得**快** —— 服务过载时快速返回 503（fail fast），这些请求**耗时极短**。它们混进整体延迟里，会把 P99 **拉低**——于是**系统越是在崩溃，延迟指标看起来越健康**。这是个极其危险的假象：告警不响，但用户全在看错误页。
  - **失败**得**慢** —— 超时的请求耗时 = 超时时间（比如 30s）。它们会把 P99 **拉高**到超时值附近，**掩盖了成功请求的真实延迟变化**。

  **正确做法：延迟按 status 分开看。**

  ```text
  # ✅ 只看成功请求的 P99(这才是"用户成功时等了多久")
  histogram_quantile(0.99,
    sum(rate(http_request_duration_seconds_bucket{status=~"2.."}[5m])) by (le)
  )

  # 失败请求的延迟单独看(它有自己的意义:失败得快还是慢?)
  histogram_quantile(0.99,
    sum(rate(http_request_duration_seconds_bucket{status=~"5.."}[5m])) by (le)
  )
  ```

  **记住这个组合：成功率（E）+ 成功请求的延迟（D）。** 这两个一起才完整描述了“用户体验”：有多少人成功了，以及成功的人等了多久。**混在一起的 P99 是个会骗人的数。**
</Callout>

## 实战：一张服务健康看板该有什么

把三套方法论落成一张**真正有用**的看板：

```mermaid
flowchart TD
    subgraph 顶部["① 用户视角(黄金信号)"]
        A1["成功率<br/>(1 - 错误率)"]
        A2["成功请求 P50/P99"]
        A3["QPS"]
        A4["饱和度:最紧的那个资源"]
    end
    subgraph 中部["② 服务视角(RED,按依赖分解)"]
        B1["本服务 RED"]
        B2["下游 A 的 RED"]
        B3["下游 B 的 RED"]
    end
    subgraph 底部["③ 资源视角(USE)"]
        C1["CPU U/S"]
        C2["内存 U/S"]
        C3["连接池 U/S ★"]
        C4["磁盘 U/S"]
    end
    顶部 -->|"出问题时向下看"| 中部
    中部 -->|"定位到某跳后向下看"| 底部
```

<Callout type="info">
  **这张看板的关键是**分层**，而不是把 50 个图平铺在一页。**

  - **第一层（4 个图）** —— 回答“**现在用户体验好吗**”。**平时只看这一层。** 全绿就可以关掉页面去干活。
  - **第二层** —— 第一层红了才看：“**是哪一跳的问题**”（[本服务还是下游](https://daiw.org/manual/observability/use-method)）。
  - **第三层** —— 定位到某一跳后才看：“**是哪个资源**”（[USE](https://daiw.org/manual/observability/use-method)）。

  **这个分层结构直接对应[上一章的排障算法](https://daiw.org/manual/observability/use-method)**：症状 → 哪一跳 → 哪个资源。看板的结构应该**长得像排障的思路**，而不是像“我们能采到的指标列表”。

  **一个检验标准**：如果值班的人被叫醒后，能**顺着看板从上往下**在 5 分钟内定位到根因，这个看板就是好的；如果他还是得去 `tail` 日志或者问人，那这个看板就是装饰品。
</Callout>

## 三套方法论速查

| 你要监控的东西 | 用 | 信号 |
| --- | --- | --- |
| HTTP/gRPC 服务、消息消费者 | **[RED](https://daiw.org/manual/observability/red-method)** | Rate、Errors、Duration |
| CPU/内存/磁盘/网络/**连接池/线程池** | **[USE](https://daiw.org/manual/observability/use-method)** | Utilization、**Saturation**、Errors |
| 整个面向用户的系统（顶层看板） | **[黄金信号](https://daiw.org/manual/observability/four-golden-signals)** | Latency、Traffic、Errors、**Saturation** |
| 业务健康 | **没有方法论** | 靠你对业务的理解（[第 1 章说过](https://daiw.org/manual/observability/metrics-methodology)） |

## 小结与下一章

**四大黄金信号 = Latency、Traffic、Errors、Saturation**，本质是 **[RED](https://daiw.org/manual/observability/red-method) + [饱和度](https://daiw.org/manual/observability/use-method)**——三套方法论是[同一片领土的三张地图](https://daiw.org/manual/observability/four-golden-signals)，不用三选一（**服务用 RED、资源用 USE、顶层看板用黄金信号**）。它最大的贡献是把**饱和度提升为服务级一等信号**，因为**饱和度是唯一有预测性的信号**（[延迟和错误都是滞后的——响的时候用户已在受苦；饱和度让你在出事前扩容](https://daiw.org/manual/observability/four-golden-signals)）；故饱和度要**看趋势和预测**（`predict_linear` 比静态阈值高明，[后者在小盘上太晚、大盘上太早](https://daiw.org/manual/observability/alert-thresholds)）。独有洞见：**成功与失败的延迟必须分开**——[失败得快会把 P99 拉低（系统越崩指标越健康，危险的假象），失败得慢会把 P99 顶到超时值（掩盖真实延迟）](https://daiw.org/manual/observability/four-golden-signals)；正确组合是**成功率 + 成功请求的延迟**。看板要**分层**（[用户视角 → 哪一跳 → 哪个资源](https://daiw.org/manual/observability/use-method)），结构应该长得像排障思路。

方法论说完了“该测什么”。接下来是“**怎么把它定义好**”——命名、标签、以及那条不能碰的基数红线。👉 [怎么定义指标](https://daiw.org/manual/observability/defining-metrics)。

## 参考资料

- [1] Google《SRE Book》第 6 章「Monitoring Distributed Systems」——四大黄金信号。
- [2] Prometheus 官方文档：`predict_linear`。
- [3] 关联[RED](https://daiw.org/manual/observability/red-method)、[USE](https://daiw.org/manual/observability/use-method)、[告警阈值](https://daiw.org/manual/observability/alert-thresholds)。