SRE 四大黄金信号详解

四大黄金信号（The Four Golden Signals）出自 Google SRE 团队，是服务监控领域被引用最多的框架。它的主张很硬核：如果只能监控四样东西，就监控延迟、流量、错误、饱和度。这四个信号覆盖了"用户正在经历什么"和"系统离崩溃还有多远"两个维度，构成服务健康的最小完备视图。

信号一：延迟（Latency）

处理一个请求花了多长时间。

两个关键细节：

1. 区分成功与失败请求的延迟。失败请求常常"快得骗人"（立即返回错误）或"慢得吓人"（超时 30 秒），混在一起算会污染数据。分开统计，各看各的。
2. 看分布，别看平均值。平均值掩盖长尾。用直方图统计分位数：P50 代表典型体验，P90 代表较慢的一成用户，P99 是体验最差的百分之一——往往是重要客户。

Prometheus 埋点示例（Node.js + prom-client）：

import { Histogram } from 'prom-client';

const requestLatency = new Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTP request latency in seconds',
  labelNames: ['method', 'route', 'status_code'],
  buckets: [0.01, 0.05, 0.1, 0.5, 1, 2.5, 5, 10]
});

function latencyMiddleware(req, res, next) {
  const start = Date.now();
  res.on('finish', () => {
    requestLatency.observe(
      { method: req.method, route: req.route?.path, status_code: res.statusCode },
      (Date.now() - start) / 1000
    );
  });
  next();
}

查询 P99：

histogram_quantile(0.99,
  sum by (route, le) (rate(http_request_duration_seconds_bucket[5m])))

信号二：流量（Traffic）

系统承受的需求量。 不同系统量纲不同：

• Web 服务：HTTP 请求/秒
• 流媒体：带宽或并发会话数
• 数据库：查询/秒、活跃连接数
• 队列消费：消息处理/秒

流量的价值在于给其他信号提供上下文：错误率 1% 在 10 QPS 和 10000 QPS 下是完全不同的严重程度。流量趋势也是容量规划的直接依据。

sum by (service) (rate(http_requests_total[5m]))

信号三：错误（Errors)

失败请求的速率。 显式的失败（HTTP 500）、隐式的失败（返回 200 但内容是错的）、以及违反 SLO 的慢请求（超过延迟阈值的"成功"响应）都算。

# 错误率
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

错误信号直接对接 SLO：如果 SLO 是"99.9% 请求成功"，错误预算消耗速率就是最好的告警输入。

信号四：饱和度（Saturation）

系统"有多满"——距离资源耗尽的余量。 它回答的是预测性问题："照这样下去，我们什么时候会出问题？"

度量角度：CPU/内存/磁盘的余量、线程池/连接池占用率、队列积压深度。对延迟敏感的服务，特别关注那些"非线性恶化"的资源——CPU 到 90% 后延迟不是涨 10%，而是可能翻倍。

# 内存饱和度
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

与其他框架的关系

• vs RED：黄金信号 = RED（流量/错误/延迟）+ 饱和度。RED 更轻，适合纯服务视角；黄金信号多了资源余量视角。
• vs USE：USE 专注资源层（利用率/饱和度/错误），黄金信号的"饱和度"正是借自 USE。
• 实务建议：服务层用黄金信号（或 RED），资源层用 USE，两者在仪表盘里上下联动。

基于黄金信号设告警

• 延迟：P99 超过 SLO 阈值持续 N 分钟 → 告警。注意区分长短尾，别被 P50 蒙蔽。
• 错误：错误率烧穿错误预算的速率（burn rate）超阈值 → 告警，比静态阈值更灵敏也更少误报。
• 饱和度：达到容量的 80% 且趋势向上 → 预警级（不进值班电话，进工单）。
• 流量：通常不直接告警，但流量异常下跌（如腰斩）本身是值得告警的信号——可能是入口挂了。

观测云对照

观测云 APM 接入后，四大黄金信号开箱即得：服务概览页直接呈现请求量、错误率、延迟分位数，主机/容器视图提供饱和度指标；监控器可按延迟 P99、错误率、资源饱和度分别设告警，错误率类告警支持按预算消耗速率触发；配合自定义仪表盘，一个页面组织好"黄金信号总览 → 服务下钻 → 资源下钻"三层视图。

常见问题（FAQ）

Q：四个信号只够做"概览"吧，排障够用吗？
A：对——黄金信号是"该看哪些"的优先级框架，不是排障的终点。它告诉你出事了、在哪类资源上；具体根因要靠日志和链路追踪下钻。

Q：延迟用平均不行吗，为什么要分位数？
A：假设 100 个请求里 99 个 10ms、1 个 10 秒，平均值 109ms 看起来还行，但那 1 个用户已经觉得系统坏了。分位数（P99/P999）专门捕捉这类长尾。

Q：批处理系统怎么套这四个信号？
A：延迟→单条/单批处理耗时，流量→处理速率，错误→失败条目占比，饱和度→队列积压与 worker 占用率。概念直接映射。