四大黄金指标是什么
Google SRE 从大量线上系统的监控实践中归纳出四类通用信号：延迟 Latency、流量 Traffic、错误 Errors、饱和度 Saturation。它们不依赖具体技术栈，任何受理请求的系统都能套用，适合作为新服务监控体系的起步清单。其价值在于用最少的指标覆盖用户可感知的健康度，而不是穷举所有可采集的数值。
基本信息
| 来源 | Google SRE Book 第 6 章 Monitoring Distributed Systems |
|---|---|
| 适用对象 | 在线请求型服务；批处理与离线任务需改用任务成功数与时效指标 |
| 四个维度 | 延迟、流量、错误、饱和度 |
| 选型要点 | 延迟必须区分成功与失败请求，饱和度偏预测性 |
典型使用场景
- 新服务监控起步：先落地四类指标，再按需补充业务指标与资源细节
- 值班告警分级：错误与延迟进电话告警，饱和度进工单或低等级通知
- 发布回归对比：发布前后比较错误率与 P95/P99 是否劣化
- 容量评估：流量增长与饱和度曲线的交点决定何时扩容
- SLO 指标选取：成功率与延迟 SLI 通常直接取自错误与延迟两类信号
四类指标
| 指标 | 含义 | 度量示例 | 异常特征 |
|---|---|---|---|
| Latency 延迟 | 请求耗时分布 | HTTP P95 耗时（成功与失败分开统计） | P95 上抬而 QPS 未涨，常见于下游劣化或资源争抢 |
| Traffic 流量 | 系统承受的请求或数据量 | 每秒请求数、每秒写入字节数 | 突增可能是业务峰值，也可能是重试风暴 |
| Errors 错误 | 请求失败的比例 | 5xx 占比、重试次数、连接被拒数 | 持续高于基线且非发布窗口，需立即定位 |
| Saturation 饱和度 | 资源接近上限的程度 | CPU 使用率、连接池占用、磁盘队列长度 | 先于延迟劣化出现，属于预测性信号 |
四类指标的简版 PromQL 实现
四类指标的简版 PromQL 实现
# 流量：每秒请求数
sum by (job) (rate(http_requests_total[5m]))
# 延迟 P95：先按 le 聚合桶再算分位
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket{job="api"}[5m])))
# 错误比例：5xx 占全部请求
sum(rate(http_requests_total{job="api",code=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="api"}[5m]))
# 饱和度：每核负载近似值
node_load1 / count by (instance) (node_cpu_seconds_total{mode="idle"})常见取舍
| 做法 | 问题 | 建议 |
|---|---|---|
| 只统计整体延迟 | 快速失败的请求拉低均值，掩盖问题 | 按 code 分组分别统计成功与失败请求 |
| 只看平均值 | 长尾体验被平均掉 | 至少看 P95 与 P99 |
| 饱和度直接做电话告警 | 多数情况无法立即行动，消耗值班精力 | 作为前置信号进入看板与工单 |
延迟要分开统计成功与失败请求：快速失败会显著拉低整体延迟曲线，让故障期的服务看起来反而更快。
四类信号覆盖不到业务正确性：接口返回 200 但下单未生效这类问题，需要额外的业务指标（下单成功率、支付转化率）来兜住。
与其他监控方法的关系
四大黄金指标、RED 与 USE 是三个互补的抽象层次：黄金指标给出适用于任何系统的四类通用信号，RED 把它收敛成请求型服务可直接落地的三个查询，USE 则专用于资源侧排查。实践中常见组合是拿黄金指标或 RED 做服务看板骨架，用 USE 检查资源瓶颈，再用业务指标补上正确性。
指标口径要与 SLO 对齐：如果 SLO 用五分钟窗口的成功率，看板与告警也应使用同一窗口与同一分母，否则同一个故障在两处会得出不同结论。
筛选信号的四问
- 这个指标异常时值班同学能做什么：无法行动的信号放看板，不要做告警
- 它能否在用户抱怨之前出现：先于用户感知的信号适合做预防性通知
- 口径是否稳定：含义随版本变动或依赖人工填写的指标很难长期维护
- 同一含义是否只保留一个指标名：多套命名并存会让看板与告警的取数逐渐分叉