4. SLI 指标设计原则：选择正确的 SLI 与采集方式
SLI（Service Level Indicator，服务等级指标）是 SLO 体系的基石。选择错误的 SLI 会导致 SLO 无法真实反映用户体验，甚至误导运维决策。本节从四大黄金指标出发，阐述 SLI 的设计原则、采集方式与数据源选型。
4.1 四大黄金指标：选择正确的 SLI
Google SRE 实践总结出四个通用 SLI 类别：延迟、错误率、吞吐量、饱和度。每个类别对应不同的用户感知维度，需根据服务类型组合使用。
| 指标类别 | 定义 | 典型测量方式 | 适用场景 |
|---|---|---|---|
| 延迟 | 请求从发出到收到完整响应的时间 | P50 / P95 / P99 分位延迟 | API 网关、数据库查询、页面加载 |
| 错误率 | 失败请求占总请求的比例 | HTTP 5xx 比例 / 业务错误码比例 | 所有在线服务 |
| 吞吐量 | 单位时间内处理的请求量或数据量 | RPS（每秒请求数）、TPS（每秒事务数） | 批处理系统、消息队列、CDN |
| 饱和度 | 资源使用程度与容量上限的比值 | CPU 使用率、内存占用、连接池水位 | 基础设施层、中间件、数据库 |
设计原则：优先选择面向用户的 SLI（延迟、错误率），而非仅关注内部资源指标（饱和度）。例如，即使 CPU 使用率低于 50%，若 P99 延迟已超过 2 秒，则用户体验已受损。
4.2 SLI 采集方式与数据源
SLI 数据源分为三类：客户端埋点、服务端日志、基础设施监控。不同数据源在准确性、覆盖面和采集成本上存在差异。
| 数据源类型 | 采集方式 | 优势 | 劣势 |
|---|---|---|---|
| 客户端埋点 | RUM（真实用户监控）、APM Agent | 最贴近真实用户体验 | 受网络波动影响，采样率受限 |
| 服务端日志 | 访问日志、结构化日志、Metrics 端点 | 数据完整，易于聚合 | 可能遗漏客户端超时导致的失败 |
| 基础设施监控 | Prometheus Exporter、CloudWatch、JMX | 覆盖资源饱和度，实时性强 | 无法直接反映用户感知 |
推荐组合：服务端日志 + 基础设施监控作为主要数据源，客户端埋点作为补充校准。例如，使用 Nginx 访问日志计算延迟和错误率，使用 Prometheus 采集 CPU/内存饱和度。
4.3 SLI 采集架构与数据流
下图展示了一个典型的 SLI 采集架构，从数据产生到 SLO 计算的全链路。
避坑提示：不要将基础设施指标直接作为用户侧 SLI。例如，CPU 使用率 90% 不一定意味着请求延迟升高；反之，CPU 使用率 30% 也可能因锁竞争导致高延迟。始终以用户感知指标为主，基础设施指标为辅。
4.4 SLI 设计检查清单
在定义每个 SLI 时，建议对照以下清单进行评审：
- 用户相关性：该指标是否直接反映用户感受到的服务质量？
- 可测量性：是否有现成的数据源或采集方式？采集频率是否满足 SLO 窗口要求？
- 可区分性：能否区分正常流量与异常流量（如爬虫、健康检查）？
- 稳定性：指标定义是否在较长时间内保持稳定，避免频繁调整？
- 可操作性：当 SLI 恶化时，团队能否快速定位根因并采取行动？
4.5 常见 SLI 定义示例
| 服务类型 | SLI 名称 | 定义公式 | 数据源 |
|---|---|---|---|
| HTTP API | 延迟 P99 | 所有成功请求中，第 99 百分位的响应时间 | Nginx 访问日志 / APM |
| HTTP API | 错误率 | HTTP 5xx 响应数 / 总请求数 × 100% | Nginx 访问日志 |
| 数据库 | 查询延迟 P95 | 所有成功查询中，第 95 百分位的执行时间 | 慢查询日志 / Prometheus |
| 消息队列 | 吞吐量 | 每秒成功投递的消息数 | Broker Metrics |
| CDN | 缓存命中率 | 缓存命中请求数 / 总请求数 × 100% | CDN 日志 |
| 计算集群 | 饱和度 | CPU 使用率 / 容量阈值 | Prometheus Node Exporter |
最佳实践：每个 SLO 至少绑定 2 个 SLI（一个用户感知指标 + 一个资源指标）。例如，API 服务的 SLO 可同时监控“P99 延迟 < 500ms”和“CPU 饱和度 < 80%”，前者保障体验，后者预警容量风险。