SLI 指标设计：延迟、流量、错误、饱和度四大黄金信号
在 SRE 实践中，SLI（Service Level Indicator，服务等级指标）是衡量服务质量最直接的量化标尺。Google 在《SRE 运维解密》中提出的四大黄金信号（Four Golden Signals）——延迟、流量、错误、饱和度，覆盖了用户感知与系统容量两个维度。本章将逐一拆解每个信号的定义原则、有效阈值设定方法，以及如何避免常见的“伪 SLI”陷阱。
2.1 四大黄金信号总览
下表对比了四个信号的核心关注点、典型测量方式与常见误区：
| 黄金信号 | 关注维度 | 典型测量方式 | 常见误区 |
|---|---|---|---|
| 延迟（Latency） | 用户等待时间 | P50 / P95 / P99 分位延迟 | 只关注平均值，忽略长尾 |
| 流量（Traffic） | 请求负载量 | QPS / RPS / 带宽 / 并发连接数 | 只统计成功请求，忽略重试 |
| 错误（Errors） | 请求失败比例 | HTTP 5xx / 4xx / 超时 / 业务错误码 | 只统计显式错误，忽略隐式错误 |
| 饱和度（Saturation） | 资源耗尽程度 | CPU 使用率 / 内存占用 / 连接池水位 / 队列深度 | 使用百分比而非余量 |
核心原则：SLI 必须从用户视角定义。例如，延迟 SLI 应测量“用户发起请求到收到完整响应的时间”，而非“服务端处理时间”。用户感知不到服务端内部的重试、缓存穿透或异步补偿逻辑。
2.2 延迟（Latency）—— 分位值比平均值更重要
延迟 SLI 是用户满意度最直接的反映。定义有效的延迟 SLI 需遵循以下步骤：
- 选择分位点：推荐使用 P50（中位数） 反映典型体验，P95 反映大多数用户，P99 反映长尾用户。避免使用平均值，因为平均值会被极端值严重扭曲。
- 设定阈值：例如“P95 延迟 ≤ 500ms”或“P99 延迟 ≤ 2s”。阈值应基于业务容忍度，而非基础设施能力。
- 区分成功与失败：延迟 SLI 通常只统计成功请求，但失败请求的延迟也应单独监控，防止“快速失败”掩盖真实问题。
案例：某 API 网关的延迟 SLI 定义为“过去 5 分钟内，所有成功请求的 P99 延迟 ≤ 1s”。若 P99 超过 1s，则触发告警。注意：该 SLI 排除了 4xx/5xx 响应，因为错误响应的延迟通常很短，会拉低整体延迟数据。
2.3 流量（Traffic）—— 区分有效负载与无效重试
流量 SLI 用于衡量系统当前承受的请求压力。定义要点：
- 明确计数对象：是 HTTP 请求数、gRPC 调用数、消息队列的入队速率，还是数据库的查询次数？
- 去重重试：客户端自动重试会导致流量虚高。SLI 应尽量统计去重后的唯一请求，或在告警时考虑重试因子。
- 区分读写：读流量与写流量的资源消耗差异巨大，建议分别定义 SLI。
| 流量类型 | 典型 SLI 定义 | 测量工具 |
|---|---|---|
| HTTP 入口 | 每分钟请求数（RPM） | 负载均衡器指标 |
| 消息队列 | 每秒入队消息数（msg/s） | Kafka / RabbitMQ 指标 |
| 数据库 | 每秒查询数（QPS） | 数据库监控插件 |
2.4 错误（Errors）—— 显式错误与隐式错误
错误 SLI 是最容易被低估的信号。除了 HTTP 5xx 和 4xx，还需关注：
- 显式错误：HTTP 500、503、504；gRPC 状态码 Internal、Unavailable；超时异常。
- 隐式错误：返回 200 但业务逻辑失败（如“下单成功”但库存扣减失败）；响应体包含错误码；响应时间极短（< 10ms）可能表示缓存穿透或空响应。
- 错误率计算：通常定义为“错误请求数 / 总请求数 × 100%”。阈值建议 ≤ 0.1% 或 ≤ 1%，视业务关键程度而定。
避坑提示：不要只监控“错误率”而忽略“错误量”。即使错误率很低（如 0.01%），如果流量巨大（如 1000 万 QPS），错误量可能达到 1000 次/秒，仍需要立即处理。
2.5 饱和度（Saturation）—— 资源余量比使用率更关键
饱和度 SLI 用于预测系统何时会达到瓶颈。定义要点：
- 选择关键资源：CPU、内存、磁盘 I/O、网络带宽、数据库连接池、线程池、队列深度。
- 使用余量而非百分比：例如“可用内存 < 2GB”比“内存使用率 > 80%”更直接。因为 80% 使用率在 8GB 内存的机器上还剩 1.6GB，而在 4GB 机器上只剩 0.8GB，风险完全不同。
- 关注队列深度：队列深度是饱和度的早期信号。例如，Tomcat 线程池的等待队列长度 > 100 时，即使 CPU 使用率只有 60%，系统也可能即将过载。
2.6 四大黄金信号的关系与联动
四个信号并非孤立存在，它们之间存在典型的因果链。下图展示了常见的故障传播路径：
2.7 定义有效 SLI 的检查清单
在定义每个 SLI 时，建议对照以下清单进行验证：
| 检查项 | 说明 | 示例 |
|---|---|---|
| 1. 用户视角 | SLI 是否反映用户真实体验？ | “端到端延迟”而非“服务端处理时间” |
| 2. 可测量性 | 指标是否能在生产环境持续采集？ | 避免依赖人工上报或采样率过低的指标 |
| 3. 可区分性 | 能否区分成功与失败、正常与异常？ | HTTP 200 但业务失败需单独标记 |
| 4. 阈值合理性 | 阈值是否基于历史数据或业务要求？ | P99 延迟阈值参考过去 30 天基线 |
| 5. 告警有效性 | SLI 触发告警后是否能指导行动？ | 避免“CPU 使用率 > 90%”这种无上下文的告警 |
2.8 实战：为采集作业平台定义 SLI
假设我们正在为“采集作业平台”设计 SLI，该平台负责从多个数据源拉取日志并写入消息队列。以下是针对四大黄金信号的具体定义：
采集作业平台 SLI 定义示例：
- 延迟：每次采集任务从开始到完成写入的 P95 耗时 ≤ 30s。
- 流量：每分钟采集的日志条数（EPS）≥ 10000 条/分钟（低于此值可能表示数据源异常）。
- 错误：采集失败的任务数 / 总任务数 ≤ 1%。失败包括：连接超时、认证失败、写入队列失败。
- 饱和度：采集作业所在主机的可用内存 ≥ 1GB，且消息队列的积压长度 ≤ 5000 条。
通过以上定义，SRE 团队可以快速定位问题：当延迟升高时，检查饱和度（内存/队列）；当错误率上升时，检查流量是否突增或数据源是否不可达。四个信号互为补充，形成完整的可观测性闭环。