📚 课程目录第2章 SLI定义与分类

2. SLI 定义与分类：延迟、流量、错误、饱和度四大黄金信号详解

在可观测性工程中，SLI（Service Level Indicator，服务等级指标）是衡量系统行为最直接的量化标尺。Google SRE 团队提出的“四大黄金信号”——延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）——构成了现代监控与异常检测的基石。本章将逐一拆解每个信号的定义、采集口径、典型阈值基线以及校准陷阱。

2.1 四大黄金信号总览

下表从定义、典型指标、采集方式、异常特征四个维度对四大黄金信号进行横向对比，帮助建立全局认知。

黄金信号	核心定义	典型 SLI 示例	采集方式	异常特征
延迟	请求从发出到收到完整响应所消耗的时间	p50 / p95 / p99 响应时间	服务端埋点、APM 探针、负载均衡日志	尾部延迟陡增、p99 超过 SLO 阈值
流量	系统在单位时间内处理的请求量或数据量	QPS、RPS、吞吐量、并发连接数	反向代理计数、服务端请求计数器	突发峰值、周期性陡降、流量超限
错误	请求处理失败或返回非预期结果的比率	HTTP 5xx 率、错误码占比、异常率	状态码统计、日志解析、健康检查	错误率突增、慢速错误累积
饱和度	系统资源被消耗的程度，越接近上限越危险	CPU 使用率、内存占用、磁盘 IO 等待	操作系统指标、中间件 exporter	资源利用率持续高位、排队深度增长

校准提示：四大信号并非孤立存在。例如，延迟升高往往由饱和度（CPU 排队）或错误（重试风暴）引发；流量突增可能先于饱和度恶化。异常检测时建议将四个信号作为联合特征输入，而非单指标告警。

2.2 延迟（Latency）—— 用户体验的标尺

延迟是最直接影响用户感知的信号。SRE 实践中，延迟 SLI 通常使用百分位值（Percentile）而非平均值，因为平均值会掩盖尾部慢请求。

p50（中位数）：反映大多数用户的体验，适合作为日常性能基线。
p95 / p99：反映尾部延迟，是 SLO 违约的主要判定依据。p99 延迟超过 500ms 通常被视为“慢体验”。
采集口径：必须区分客户端视角（包含网络延迟）与服务端视角（仅处理时间）。SLI 口径应明确声明测量点。

  基线阈值示例：

  SLI：p99 响应时间 ≤ 200ms（服务端）

  异常检测基线：基于过去 7 天同一时段 p99 的移动平均值 ± 2σ

  告警触发：连续 3 个数据点超过基线 1.5 倍

2.3 流量（Traffic）—— 系统压力的前哨

流量信号反映系统当前承载的请求规模。异常检测中，流量通常作为上下文指标，用于判断其他信号的变化是否由负载变化引起。

QPS（每秒查询数）：最通用的流量 SLI，适用于 HTTP API、数据库查询。
RPS（每秒请求数）：与 QPS 类似，但更强调完整请求生命周期。
并发连接数：适用于长连接场景（WebSocket、gRPC Stream）。
吞吐量（Bytes/s）：适用于数据传输型服务（CDN、消息队列）。

流量异常检测的难点在于周期性模式与突发峰值的区分。例如，电商大促的流量高峰是正常业务行为，而凌晨 3 点的流量突增则可能是爬虫攻击。

2.4 错误（Errors）—— 故障的直接证据

错误信号是最直观的故障指示器，但定义错误 SLI 时需注意显式错误与隐式错误的区别。

错误类型	定义	示例	检测难度
显式错误	协议层明确返回的错误状态码	HTTP 500、503、gRPC UNAVAILABLE	低（直接计数）
隐式错误	业务逻辑错误但协议层返回成功	HTTP 200 但响应体包含 error 字段	高（需解析响应体）
慢错误	请求超时或客户端放弃等待	客户端 30s 超时断开连接	中（需客户端配合）

常见陷阱：仅监控 HTTP 5xx 会漏掉大量隐式错误。例如，支付服务返回 HTTP 200 但 body 中 "status":"failed"，这种错误对用户的影响与 500 无异。建议在 SLI 口径中明确包含业务错误码。

2.5 饱和度（Saturation）—— 容量瓶颈的预警

饱和度衡量系统资源的使用程度。当资源利用率接近 100% 时，系统通常会出现排队、抖动甚至崩溃。饱和度 SLI 的关键在于找到最受限的资源。

CPU 饱和度：使用率 > 80% 时，CPU 调度延迟开始显著增加。
内存饱和度：可用内存不足触发 OOM Killer 或频繁 Swap。
磁盘 I/O 饱和度：IOPS 或吞吐量达到设备上限，导致读写延迟飙升。
网络饱和度：带宽耗尽导致丢包和重传。
连接池/线程池饱和度：池中资源耗尽，新请求被阻塞或拒绝。

饱和度异常检测通常使用利用率 + 排队深度的组合指标。例如，CPU 使用率 70% 可能正常，但如果运行队列长度持续超过 CPU 核心数的 2 倍，则说明系统已经饱和。

2.6 四大黄金信号的关联与校准

下图展示了四大黄金信号在典型故障场景中的因果传导关系，帮助理解为何异常检测需要联合分析。

2.7 SLI 口径基线设定原则

为每个黄金信号设定 SLI 口径时，必须明确以下三个要素：

测量窗口：例如“过去 1 分钟内的 p99 延迟”，窗口大小影响检测灵敏度。
聚合方式：平均值、百分位值、速率（rate）、比率（ratio）。错误信号通常使用错误率（错误请求数 / 总请求数）而非计数。
基线来源：静态阈值（如 p99 < 200ms）适用于已知容量边界；动态基线（如基于历史数据的移动平均 ± 3σ）适用于周期性变化的业务。

基线校准案例：
某 API 网关的延迟 SLI 口径：

SLI: http_request_duration_seconds{quantile="0.99"} 
窗口: 5 分钟滑动窗口
基线: 过去 7 天同一 5 分钟窗口的 p99 中位数 × 1.5
告警: 连续 2 个窗口超过基线

该口径同时考虑了周期性（7 天同窗口）和容忍度（1.5 倍），避免因短期抖动误告警。

2.8 四大信号联合检测策略

单一信号的异常检测容易产生误报。推荐使用信号关联矩阵进行联合判断：

检测场景	延迟	流量	错误	饱和度	可能根因
流量突增 + 饱和度上升	↑	↑↑	→	↑	正常业务高峰，需扩容
延迟升高 + 饱和度上升	↑↑	→	→	↑↑	资源瓶颈，代码效率问题
错误率上升 + 延迟不变	→	→	↑↑	→	依赖服务故障、配置错误
延迟升高 + 错误率上升	↑↑	→	↑	↑	系统过载，即将雪崩

实践建议：在构建异常检测模型时，将四大黄金信号作为特征向量输入，使用孤立森林或时序异常检测算法（如 Twitter's AnomalyDetection）进行多变量联合检测，比单指标阈值告警准确率提升 40% 以上。