1. 黄金指标概述

1.1 什么是黄金指标

黄金指标（Golden Signals）是业界经过大量生产环境验证后提炼出的一组高价值、高可操作性的监控度量体系。它们之所以被称为“黄金”，是因为这些指标能够以最少的维度覆盖系统健康状态的核心信息，帮助 SRE 团队快速定位问题、评估影响并指导恢复动作。

目前业界公认的三大黄金指标体系包括：

体系 全称 核心关注点 适用场景
USE Utilization / Saturation / Errors 资源视角：使用率、饱和度、错误 基础设施层（CPU、内存、磁盘、网络）
RED Rate / Errors / Duration 服务视角：请求速率、错误率、延迟 微服务、API 网关、中间件
四大黄金信号 Latency / Traffic / Errors / Saturation 用户视角：延迟、流量、错误、饱和度 全栈可观测性、用户体验监控
核心原则： 黄金指标不是越多越好，而是“最少必要指标”。一个系统如果只允许监控 4 个指标，那么四大黄金信号就是最佳选择；如果只允许 3 个，RED 或 USE 则更聚焦。

1.2 为什么需要黄金指标

在事故响应场景中，监控数据爆炸是一个真实痛点。一个中等规模的微服务系统可能产生数万个指标，但其中 90% 在事故发生时是噪声。黄金指标的价值体现在以下四个维度：

  • 降低认知负载： 将数千个指标压缩为 3-4 个关键维度，缩短 MTTR（平均修复时间）中的“识别”阶段。
  • 统一沟通语言： 开发、运维、业务团队使用同一套指标体系讨论事故，减少跨团队对齐成本。
  • 提升告警信噪比： 黄金指标天然具备高信号密度，基于它们设计的告警规则误报率远低于随机指标。
  • 支撑自动化决策： 黄金指标是自动化扩缩容、故障自愈、混沌工程等高级运维能力的数据基础。
实践建议： 在搭建新系统的可观测性体系时，优先从四大黄金信号开始，再根据业务特性补充领域特定指标（如数据库连接池使用率、消息队列积压量）。不要一开始就追求“全量采集”。

1.3 黄金指标与事故响应的关系

事故响应流程通常包含五个阶段：检测 → 告警 → 诊断 → 恢复 → 复盘。黄金指标在每个阶段都扮演着不可替代的角色：

  1. 检测阶段： 黄金指标是异常检测算法的输入源。例如，延迟的突然升高（Latency）或错误率突破基线（Errors）是事故的第一信号。
  2. 告警阶段： 基于黄金指标设计的告警阈值具有明确的业务语义，避免“告警风暴”。例如，CPU 使用率 95% 是 USE 中的饱和度告警。
  3. 诊断阶段： 通过对比 RED 和 USE 指标，可以快速区分“是服务自身问题”还是“底层资源瓶颈”。例如，服务延迟升高但资源饱和度正常，则问题大概率在应用代码层面。
  4. 恢复阶段： 黄金指标是恢复动作是否生效的验证标准。例如，扩缩容后观察 Saturation 是否回落。
  5. 复盘阶段： 黄金指标的时间序列数据是事故根因分析的核心证据，也是后续调整告警阈值的依据。
常见误区： 不要将黄金指标当作“事后分析”工具。黄金指标的核心价值在于“实时指导响应动作”。如果事故发生时你还需要打开多个仪表盘才能拼凑出系统状态，说明你的黄金指标体系尚未落地。

1.4 三大黄金指标体系对比

为了帮助你在实际工作中选择合适的体系，下表从多个维度进行了对比：

对比维度 USE RED 四大黄金信号
提出者 Brendan Gregg Tom Wilkie（Weaveworks） Google SRE 团队
指标数量 3 3 4
关注层级 基础设施资源 服务/应用 全栈（用户→服务→资源）
典型指标示例 CPU 使用率、磁盘 I/O 等待、内存 OOM 计数 QPS、HTTP 500 比例、P99 延迟 请求延迟、每秒请求数、错误率、队列深度
告警设计难度 低（阈值相对固定） 中（需要动态基线） 高（需要多维关联）
推荐组合 USE + RED 互补 RED + 四大黄金信号 四大黄金信号 + USE 下沉

1.5 黄金指标体系关系图

下图展示了三大黄金指标体系在系统监控栈中的层级关系与数据流向：

黄金指标体系层级关系 用户感知层 — 四大黄金信号 Latency（延迟）| Traffic（流量）| Errors（错误）| Saturation（饱和度） 来源：Google SRE 白皮书 · 关注用户体验与系统整体健康 服务调用层 — RED 指标 Rate（请求速率）| Errors（错误率）| Duration（延迟） 来源：Tom Wilkie · 关注微服务与 API 的请求生命周期 基础设施层 — USE 指标 Utilization（使用率）| Saturation（饱和度）| Errors（错误） 来源：Brendan Gregg · 关注 CPU/内存/磁盘/网络资源瓶颈 事故响应中：自上而下逐层排查，自下而上定位根因

1.6 黄金指标在事故响应中的工作流

下图展示了从指标采集到事故恢复的完整数据流，以及黄金指标在每个环节的输入输出：

黄金指标事故响应工作流 指标采集 USE/RED/4信号 动态基线 滑动窗口/分位数 告警触发 阈值/异常检测 关联诊断 RED vs USE 恢复验证 指标回落确认 事故复盘 基线调优 关键反馈闭环 ① 告警触发后，通过 RED vs USE 对比快速定位故障层 ② 恢复验证必须依赖黄金指标回落，而非“感觉正常” ③ 复盘结果反哺基线模型，形成持续优化闭环

1.7 选择黄金指标体系的决策原则

在实际落地时，不同团队面临的技术栈和业务场景差异很大。以下决策树可以帮助你快速选择最适合的黄金指标组合：

决策原则：
  • 如果你在排查“机器为什么卡”： 优先 USE 指标（CPU 使用率、磁盘 I/O 饱和度、内存错误计数）。
  • 如果你在排查“接口为什么慢”： 优先 RED 指标（QPS、错误率、P99 延迟）。
  • 如果你需要“全栈可观测性”： 以四大黄金信号为顶层框架，USE 和 RED 作为下层实现。
  • 如果你在建设告警体系： 从 RED 开始，因为服务级指标的业务语义最清晰，告警阈值更容易与 SLO 对齐。

1.8 常见问题与避坑指南

常见问题 错误做法 正确做法
指标过多 采集所有指标，期望“全面覆盖” 先落地黄金指标，再按需补充领域指标
告警阈值固定 使用静态阈值（如 CPU > 90%） 结合动态基线，根据业务周期自动调整
忽略饱和度 只监控使用率，忽略排队/等待 USE 中的 Saturation 和四大信号中的 Saturation 必须包含
指标孤岛 RED 和 USE 分开存储，无法关联 使用统一的可观测性平台，支持指标关联查询
← 上一章 📖 返回目录 下一章 →