第 2 部分导论 · 别拍脑袋定指标 · 指标采集与观测

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

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

第 1 部分讲完了“指标怎么被拿到”。但有个更前置、也更决定成败的问题：你到底该定义哪些指标？

这一部分是整个专栏最“实战”的部分之一。它不讲源码，讲决策——因为埋点那一刻的决定，决定了你日后能问什么问题、要付多少钱、以及半夜会不会被没用的告警吵醒。

典型的失败路径：“想到什么加什么”。

症状很典型：

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

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

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

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

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

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

方法论	提出者	视角	三/四个信号
RED	Tom Wilkie	服务（请求驱动的东西）	Rate、Errors、Duration
USE	Brendan Gregg	资源（CPU/内存/磁盘/网络）	Utilization、Saturation、Errors
黄金信号	Google SRE	面向用户的系统	Latency、Traffic、Errors、Saturation

图表加载中…

一句话选型：测“服务”用 RED，测“资源”用 USE。

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

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

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

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

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

先看最常用的一个：服务视角的 RED。👉 RED 方法。