# 第 2 部分导论 · 别拍脑袋定指标

> 大多数团队的监控是「想到什么加什么」，结果是几百个没人看的面板和答不上关键问题的仪表盘。这一章讲清为什么需要方法论，并给出三大方法论（RED/USE/黄金信号）的分工与选择依据。

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

# 第 2 部分导论 · 别拍脑袋定指标

[第 1 部分](https://daiw.org/manual/observability/prometheus-architecture)讲完了“**指标怎么被拿到**”。但有个更前置、也更决定成败的问题：**你到底该定义哪些指标？**

这一部分是整个专栏最“实战”的部分之一。它不讲源码，讲**决策**——因为[埋点那一刻的决定](https://daiw.org/manual/observability/data-journey)，决定了你日后能问什么问题、要付多少钱、以及半夜会不会被没用的告警吵醒。

## 大多数监控是怎么烂掉的

<Callout type="warn">
  **典型的失败路径：“**想到什么加什么**”。**

  1. 上线前，有人说“加个监控吧”，于是加了 CPU、内存、磁盘。
  2. 出了次故障，复盘说“当时要是有 XX 指标就好了”，于是加上 XX。
  3. 换个人接手，他有自己的偏好，又加了一批。
  4. 一年后：**300 个面板、80 条告警规则、没人知道哪个重要**，出故障时大家还是在**猜**。

  症状很典型：
  - **指标很多，但答不上关键问题** —— “用户现在体验好吗？”没人能一句话回答。
  - **告警很多，但没人看** —— 每天几十条，全员静音，[真出事时淹没在噪音里](https://daiw.org/manual/observability/alerting-philosophy)。
  - **面板很漂亮，但排障时没用** —— 故障时大家还是去 `tail` 日志。
  - **账单很贵** —— [基数爆炸](https://daiw.org/manual/observability/defining-metrics)，但没人敢删，因为“万一有人在用”。

  **根因是没有方法论**：每个指标都是**孤立地**因为某个理由被加进来，彼此之间没有结构，合起来回答不了任何完整的问题。
</Callout>

## 方法论解决什么

方法论的价值不是“告诉你加哪几个指标”，而是给你一个**完备性的框架**：

<Callout type="info">
  **好的指标方法论回答两个问题：①**该测什么**（而不是能测什么）；②**测全了没有**。**

  - **该测什么** —— 从“**用户/系统的体验**”倒推，而不是从“**这个库能吐什么**”正推。大多数烂监控的根源就是**正推**：Go runtime 能吐 GC 指标，那就加上；数据库驱动能吐连接池，那就加上——**但没人问过“这些能回答什么问题”**。
  - **测全了没有** —— 方法论给你一个**小而完备**的清单。RED 说“服务只需要这三个”，USE 说“资源只需要这三个”。**完备性**意味着：如果这三个都正常，你的服务/资源大概率没问题；如果有问题，大概率能从这三个里看出来。

  **“小而完备”是关键**：三个指标你会认真看、认真定阈值、认真告警；三十个指标你只会无视它们。**监控的敌人从来不是“数据不够”，而是“信噪比太低”。**
</Callout>

## 三大方法论：各管一个视角

业界收敛出的三套方法论，**不是竞争关系，而是不同视角**：

| 方法论 | 提出者 | 视角 | 三/四个信号 |
| --- | --- | --- | --- |
| **[RED](https://daiw.org/manual/observability/red-method)** | Tom Wilkie | **服务**（请求驱动的东西） | **R**ate、**E**rrors、**D**uration |
| **[USE](https://daiw.org/manual/observability/use-method)** | Brendan Gregg | **资源**（CPU/内存/磁盘/网络） | **U**tilization、**S**aturation、**E**rrors |
| **[黄金信号](https://daiw.org/manual/observability/four-golden-signals)** | Google SRE | **面向用户的系统** | Latency、Traffic、Errors、Saturation |

```mermaid
flowchart TD
    U["用户"] -->|"请求"| S["你的服务<br/>← RED / 黄金信号<br/>(请求视角:速率/错误/延迟)"]
    S -->|"消耗"| R["底层资源<br/>CPU/内存/磁盘/网络<br/>← USE<br/>(资源视角:使用率/饱和度/错误)"]
    S -.->|"依赖"| D["下游服务<br/>← 也用 RED"]
    style S fill:#3b82f6,color:#fff
    style R fill:#f59e0b,color:#000
```

<Callout type="info">
  **一句话选型：**测“**服务**”用 [RED](https://daiw.org/manual/observability/red-method)，测“**资源**”用 [USE](https://daiw.org/manual/observability/use-method)**。**

  - 你的 **HTTP 服务、gRPC 服务、消息消费者、数据库**（作为一个服务看）—— 都是“**接收请求、处理、返回**”的东西，用 **RED**。
  - 你的 **CPU、内存、磁盘、网络、连接池、线程池、队列** —— 都是“**有容量、会被占用、会饱和**”的东西，用 **USE**。
  - **[黄金信号](https://daiw.org/manual/observability/four-golden-signals)** 基本是 RED + 饱和度，更偏“面向用户的整体系统”视角。它和 RED 高度重叠，[后面会讲清两者关系](https://daiw.org/manual/observability/four-golden-signals)。

  **实战组合拳**：对每个服务上 RED，对每类资源上 USE。这两套加起来，覆盖了绝大多数系统的绝大多数故障——而且**总共只有六个概念**，任何人都能记住。
</Callout>

## 一个重要的补充：方法论不够用的地方

<Callout type="warn">
  **必须诚实地说：RED/USE 是**通用骨架**，不是全部。它们覆盖不了两类东西：**

  - **业务指标** —— “订单成功率”、“支付金额”、“库存不足的次数”。这些**没有通用方法论**，只能靠你对业务的理解。但它们往往是**最有价值的指标**：技术指标全绿而订单量掉了一半，这种事真实发生过。**RED 覆盖“系统健康”，业务指标覆盖“业务健康”，两者都要。**
  - **系统特有的关键内部状态** —— 比如 Kafka 的 consumer lag、数据库的复制延迟、证书的剩余有效期。这些不是 RED 也不是 USE，但漏了会出大事。

  **正确的姿势是：先用 RED/USE 铺好骨架（保证不漏基础），再针对性地补业务指标和关键内部状态。** 方法论给你 80% 的覆盖和 100% 的结构，剩下 20% 靠你对系统的理解——**但没有那 80% 的骨架，你的 20% 也无处安放**。
</Callout>

## 这一部分怎么安排

- [RED 方法](https://daiw.org/manual/observability/red-method) —— 服务视角的三个信号，含完整 PromQL 实现。
- [USE 方法](https://daiw.org/manual/observability/use-method) —— 资源视角的三个信号，**饱和度是精髓**。
- [四大黄金信号](https://daiw.org/manual/observability/four-golden-signals) —— Google SRE 的版本，以及它和 RED/USE 的关系。
- [怎么定义指标](https://daiw.org/manual/observability/defining-metrics) —— 命名规范、标签设计、**基数控制的硬规则**。
- [常见指标的合理范围](https://daiw.org/manual/observability/metric-ranges) —— **多少算正常？** 这一章给具体数字。

## 小结与下一章

大多数监控烂在“**想到什么加什么**”——指标孤立、无结构，结果是[面板很多但答不上关键问题、告警很多但没人看](https://daiw.org/manual/observability/alerting-philosophy)。方法论的价值是给出**完备性框架**：回答“[**该**测什么](https://daiw.org/manual/observability/metrics-methodology)”（从体验倒推，而非从“库能吐什么”正推）和“[测全了没有](https://daiw.org/manual/observability/metrics-methodology)”。**“小而完备”是关键**——[监控的敌人是信噪比，不是数据不够](https://daiw.org/manual/observability/alerting-philosophy)。三大方法论是**不同视角**而非竞品：**[RED](https://daiw.org/manual/observability/red-method) 测服务**、**[USE](https://daiw.org/manual/observability/use-method) 测资源**、**[黄金信号](https://daiw.org/manual/observability/four-golden-signals)** 偏面向用户的整体。但要诚实：它们覆盖不了[**业务指标**](https://daiw.org/manual/observability/metrics-methodology)（往往最有价值）和[**系统特有的关键内部状态**](https://daiw.org/manual/observability/metric-ranges)——**先用 RED/USE 铺骨架，再补这两类**。

先看最常用的一个：服务视角的 RED。👉 [RED 方法](https://daiw.org/manual/observability/red-method)。

## 参考资料

- [1] Tom Wilkie「The RED Method: How To Instrument Your Services」。
- [2] Brendan Gregg「The USE Method」。
- [3] Google《SRE Book》第 6 章 Monitoring Distributed Systems（四大黄金信号）。