2. SLI 口径定义
SLI（Service Level Indicator，服务等级指标）是衡量系统某一特定方面表现的可量化度量。而 SLI 口径 则是对该度量在“采集什么、如何计算、何时生效”三个维度上的精确约定。口径不一致，即使指标名称相同，最终数据也可能天差地别——这正是 Collector 配置影响数据完整性的根源。
2.1 什么是 SLI 口径
SLI 口径可以理解为指标的“测量协议”，它包含以下核心要素：
- 测量对象：明确被测量的服务、接口或资源（如 /api/order、MySQL 连接池）。
- 测量方法：数据如何被采集（请求日志、埋点、Prometheus 拉取、Agent 推送）。
- 聚合规则：原始数据如何转换为指标（平均值、百分位数、速率、计数）。
- 有效区间：哪些数据点被纳入计算（排除健康检查、排除超时重试、仅统计 2xx/4xx/5xx）。
关键认知：Collector 配置直接决定了上述四个要素的实现方式。例如，
otelcol 的 batch processor 会改变数据的时间窗口，filter processor 会剔除特定状态码——这些都会改变 SLI 口径的实际含义。
2.2 常见 SLI 类型
业界通常将 SLI 分为四大黄金信号，每种类型在 Collector 配置中都有不同的口径敏感点：
| SLI 类型 | 定义 | 典型口径 | Collector 配置风险 |
|---|---|---|---|
| 延迟 | 请求从发出到收到完整响应的时间 | p50 / p95 / p99（毫秒） | 采样率不足导致高百分位失真；批处理引入额外排队延迟 |
| 错误率 | 失败请求占总请求的比例 | 5xx 占比 / 超时占比 / 业务错误码占比 | 状态码过滤规则不一致；重试请求被重复计数 |
| 吞吐量 | 单位时间内成功处理的请求数 | RPS（每秒请求数）/ TPS（每秒事务数） | 批处理合并导致峰值削平；采样丢失导致低估 |
| 饱和度 | 系统资源被使用的程度 | CPU 使用率 / 内存占用 / 队列深度 | 采集周期不匹配；指标聚合方式掩盖瞬时尖峰 |
实践建议：在定义 SLI 口径时，应同时记录 Collector 侧的配置快照（如
batch timeout、sampling ratio、filter conditions），以便后续审计口径一致性。
2.3 口径的粒度与维度
口径的粒度决定了 SLI 的“分辨率”，而维度决定了 SLI 的“切片能力”。两者共同影响数据完整性的可验证性。
粒度层级
- 请求级：每条请求独立记录，精度最高，但存储成本大。Collector 通常需要
tail-based sampling来降本。 - 窗口级：按固定时间窗口（如 1 分钟）聚合。Collector 的
metricstransform processor可调整窗口大小。 - 服务级：整个服务聚合为一个值。口径最粗，容易掩盖局部问题。
维度切片
常见的 SLI 维度包括：
| 维度 | 示例值 | 口径完整性影响 |
|---|---|---|
| 端点（endpoint） | /api/checkout, /api/login | Collector 路由规则若遗漏新端点，该端点 SLI 直接缺失 |
| 状态码（status_code） | 200, 429, 503 | filter processor 若误过滤 429，错误率 SLI 偏低 |
| 实例（instance） | pod-abc, pod-xyz | Collector 负载均衡若跳过某实例，该实例 SLI 为零 |
| 地域（region） | us-east-1, eu-west-2 | Collector 部署拓扑若未覆盖某地域，该地域 SLI 缺失 |
2.4 口径一致性原则
在 Collector 配置管理中，应遵循以下原则确保 SLI 口径的数据完整性：
- 显式声明：在 Collector 配置文件的注释或外部文档中，明确记录每个指标的 SLI 口径定义。
- 版本对齐：SLI 口径版本号与 Collector 配置版本号绑定，变更时同步更新。
- 可追溯：每个指标数据点应携带口径标识（如
sli_version: v2.3），便于下游校验。 - 边界测试：在 Collector 配置上线前，使用已知数据源验证口径计算结果是否与预期一致。
常见陷阱：团队在定义 SLI 时只写“延迟 p99”，但未指定是“端到端延迟”还是“服务端处理延迟”。Collector 若在客户端埋点，则包含网络延迟；若在服务端埋点，则仅含处理时间。两者口径不同，不可直接对比。