2. SLI 基础回顾:SLI 定义、黄金信号与可观测性数据的关系

2.1 什么是 SLI(Service Level Indicator)?

SLI(服务等级指标)是对服务行为某个方面的量化度量。在可观测性体系中,SLI 是连接原始观测数据与业务目标的桥梁——它将海量的 traces、metrics、logs 提炼为少数几个可比较、可聚合的数值。

维度 说明 典型表达式
定义方式 好事件计数 / 总事件计数 good_count / total_count
聚合粒度 通常按时间窗口(1min、5min、1h)滑动计算 rate(good[5m]) / rate(total[5m])
阈值判定 每个请求/事务被标记为“好”或“坏” 延迟 ≤ 200ms → good;> 200ms → bad
输出形式 0~1 之间的比率,常转换为百分比 0.999 → 99.9%
关键认知:SLI 不是原始指标,而是经过阈值映射后的比率。采样策略直接影响“好/坏”判定的准确性,进而扭曲 SLI 数值。

2.2 黄金信号(The Four Golden Signals)

Google SRE 经典著作中定义的四个黄金信号,是构建 SLI 最常用的维度框架。每个信号对应一类典型的用户或系统行为,且与可观测性数据类型有明确的映射关系。

黄金信号与可观测性数据映射 延迟 Latency 流量 Traffic 错误 Errors 饱和度 Saturation Metrics / Traces 请求耗时分布 Span 持续时间 Metrics / Logs 请求速率 (RPS) 并发连接数 Traces / Logs HTTP 状态码 异常堆栈 Metrics CPU/内存使用率 队列深度 SLI = 好事件计数 / 总事件计数 每个黄金信号都需要定义“好”的阈值,采样偏差会直接改变分子/分母

2.3 各黄金信号的 SLI 定义示例

2.3.1 延迟(Latency)

  • SLI 定义:请求在 p99 ≤ 200ms 内的比例
  • 好事件:响应时间 ≤ 200ms 的请求
  • 总事件:所有被观测到的请求
  • 数据来源:Span 的 end_time - start_time,或 Metric 的 http_request_duration_seconds
  • 采样风险:尾部延迟采样不足时,p99 估计值严重偏小,SLI 虚高

2.3.2 流量(Traffic)

  • SLI 定义:请求成功率 ≥ 99.9% 的时间占比
  • 好事件:每分钟请求数在预期范围内(无突增/突降)
  • 总事件:所有分钟窗口
  • 数据来源:Metric 的 requests_total 速率
  • 采样风险:流量 SLI 通常基于计数指标,受采样影响较小;但若使用基于 trace 的计数,低采样率会导致分母失真

2.3.3 错误(Errors)

  • SLI 定义:非 5xx 响应比例 ≥ 99.95%
  • 好事件:HTTP 状态码 < 500 的请求
  • 总事件:所有请求
  • 数据来源:Span 属性 http.status_code,或 Log 中的错误记录
  • 采样风险:错误率通常较低(< 1%),若采样策略对错误请求降权,SLI 会错误地显示为 100%

2.3.4 饱和度(Saturation)

  • SLI 定义:CPU 使用率 < 80% 的时间占比 ≥ 99%
  • 好事件:资源利用率低于阈值的观测点
  • 总事件:所有观测点
  • 数据来源:Metric 的 system.cpu.usage、jvm.memory.used
  • 采样风险:饱和度指标通常由 Metrics 承载,采样影响较小;但若使用 trace 推断饱和度(如队列等待时间),则受采样偏差影响

2.4 SLI 与可观测性数据的关系矩阵

黄金信号 主要数据源 OpenTelemetry 信号类型 采样敏感度 典型 SLI 表达式
延迟 Span 持续时间 Traces 高 latency_p99 ≤ 200ms
流量 请求计数 Metrics 低 request_rate ≥ 1000 rps
错误 状态码 / 异常事件 Traces + Logs 高 error_rate ≤ 0.1%
饱和度 资源利用率 Metrics 低 cpu_usage < 80%
核心结论:延迟和错误这两个黄金信号对采样策略高度敏感,因为它们依赖 Traces 数据来判定“好/坏”。流量和饱和度主要依赖 Metrics,受采样影响较小。因此,在设计采样策略时,必须优先保护延迟和错误相关 trace 的完整性。

2.5 从原始数据到 SLI 的转换管道

理解 SLI 的生成过程,有助于定位采样策略在哪个环节引入偏差:

  1. 数据采集:OpenTelemetry SDK 生成 Span、Metric、Log 记录
  2. 采样决策:Sampler 决定保留或丢弃 trace(头部采样)或 Span(尾部采样)
  3. 数据导出:被保留的数据发送到后端(如 Jaeger、Prometheus、Loki)
  4. 指标聚合:后端对保留数据计算 good_count 和 total_count
  5. SLI 计算:good_count / total_count 得到 SLI 值
  6. SLO 评估:将 SLI 与目标阈值(如 99.9%)比较

采样策略作用于第 2 步,直接影响第 4 步的分子和分母。如果采样策略对“好”请求和“坏”请求的保留概率不一致,SLI 就会产生系统性偏差。

从原始数据到 SLI 的管道(采样影响位置) ① 数据采集 ② 采样决策 ③ 数据导出 ④ 指标聚合 ⑤ SLI 计算 ⑥ SLO 评估 ⚠ 采样偏差注入点 分子/分母同时受影响

2.6 采样偏差对 SLI 的典型影响模式

采样策略 对延迟 SLI 的影响 对错误 SLI 的影响 偏差方向
固定概率采样(如 10%) 尾部延迟样本不足,p99 估计偏低 错误样本按比例减少,统计显著性下降 SLI 可能虚高
头部一致性采样(TraceId 哈希) 完整 trace 保留,但低延迟 trace 占比过高 错误 trace 若被哈希排除则完全丢失 SLI 可能虚高
尾部延迟采样(仅保留慢 trace) 延迟 SLI 分母被扭曲,好事件占比被低估 错误 trace 若与慢请求相关则被保留 SLI 可能虚低
错误优先采样(保留所有错误 trace) 对延迟 SLI 影响较小 错误计数准确,但分母可能被高估 错误 SLI 准确,延迟 SLI 受间接影响
实践警告:不要假设“采样率足够高就能消除偏差”。即使采样率为 50%,如果采样策略对慢请求和快请求的保留概率不同,SLI 仍然会产生系统性偏差。偏差消除的关键是保真度(fidelity)而非采样率值。