3. SLI 指标设计原则：如何为不同服务选择合适的 SLI 指标
SLI（Service Level Indicator）是 SLO 工程的基石。选错 SLI，后续的 SLO 计算、错误预算和告警都会失去意义。本章从四个典型服务类型出发，给出 SLI 指标的选择原则与落地模板。
3.1 SLI 指标的三类黄金信号
Google SRE 经典著作中定义了服务的四个黄金信号：延迟、错误率、流量、饱和度。在 SLI 实践中，我们通常聚焦于以下三类核心指标：
| 指标类别 | 定义 | 典型度量方式 |
|---|---|---|
| 延迟 (Latency) | 请求从发出到收到完整响应的时间 | p50 / p95 / p99 分位数，单位 ms |
| 错误率 (Error Rate) | 失败请求占总请求的比例 | HTTP 5xx / 4xx 占比，gRPC 非 OK 状态占比 |
| 吞吐量 (Throughput) | 单位时间内成功处理的请求数 | RPS（每秒请求数），QPS（每秒查询数） |
实践要点：不要试图监控所有指标。每个服务只选 2~3 个最能反映用户体验的 SLI，否则会陷入指标爆炸。
3.2 不同服务类型的 SLI 选择策略
不同服务的架构特征和用户期望差异巨大，SLI 的选择必须因服务制宜。下面给出四种典型服务的 SLI 推荐模板。
3.2.1 HTTP API 服务
HTTP API 是用户直接感知的入口，SLI 应优先反映端到端体验。
- 延迟：p99 延迟 < 200ms（高优先级），p50 延迟 < 50ms
- 错误率：HTTP 5xx 占比 < 0.1%，HTTP 4xx 按业务场景单独统计
- 吞吐量：峰值 RPS 不低于基线 80%（用于容量预警）
# Prometheus SLI 示例：HTTP API 延迟 p99
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{job="api-gateway"}[5m])) by (le)
)3.2.2 gRPC 服务
gRPC 通常用于内部微服务通信，延迟要求更高，错误码语义更丰富。
- 延迟：p99 延迟 < 50ms（内部调用），p95 延迟 < 20ms
- 错误率：非 OK 状态（包括 DeadlineExceeded、Unavailable）占比 < 0.5%
- 吞吐量：按 method 维度统计 RPS，关注突发流量
# Prometheus SLI 示例：gRPC 错误率
sum(rate(grpc_server_handled_total{grpc_code!="OK"}[5m]))
/
sum(rate(grpc_server_handled_total[5m]))3.2.3 数据库服务
数据库的 SLI 更关注查询性能和连接健康度，而非 HTTP 状态码。
- 延迟：慢查询占比（执行时间 > 1s 的查询比例）< 1%
- 错误率：连接超时、死锁、主从复制延迟 > 5s 视为错误
- 吞吐量：QPS 与连接池使用率，避免连接耗尽
避坑提示：数据库的“错误率”不能直接用 HTTP 5xx 衡量。应监控
mysql_global_status_aborted_connections、pg_stat_database.xact_commit 等原生指标。
3.2.4 批处理服务
批处理（如定时任务、数据管道）的 SLI 与传统在线服务不同，更关注完成度和时效性。
- 延迟：作业完成时间（Job Duration）与预期基线对比，超时 20% 视为异常
- 错误率：失败任务数 / 总任务数，允许重试后的最终成功率
- 吞吐量：单位时间处理的数据量（条数/分钟），用于判断作业是否卡住
# Prometheus SLI 示例：批处理作业完成时间
histogram_quantile(0.95,
sum(rate(job_duration_seconds_bucket{job_type="data_pipeline"}[1h])) by (le)
)3.3 SLI 选择原则总结
下表汇总了四类服务的 SLI 推荐组合，方便你在实际项目中快速套用。
| 服务类型 | 首选 SLI | 次选 SLI | 监控工具示例 |
|---|---|---|---|
| HTTP API | p99 延迟 | 5xx 错误率 | Prometheus + Blackbox Exporter |
| gRPC | p99 延迟 | 非 OK 状态占比 | Prometheus + gRPC Metrics |
| 数据库 | 慢查询占比 | 连接池使用率 | mysqld_exporter / pg_exporter |
| 批处理 | 作业完成时间 | 失败任务率 | Pushgateway + 自定义 Exporter |
3.4 SLI 指标设计流程
选择 SLI 不是一次性的工作，建议按以下步骤迭代：
- 识别用户旅程：列出服务对外提供的核心功能（如登录、查询、下单）。
- 定义好与坏：明确什么算“成功请求”，什么算“失败请求”。
- 选择黄金信号：从延迟、错误率、吞吐量中选 2~3 个。
- 设定分位数：高优先级服务用 p99，内部服务用 p95。
- 验证可观测性：确认 Prometheus 能采集到对应指标，且 cardinality 可控。
关键原则：SLI 必须可测量、可对比、可告警。如果一个指标无法在 Prometheus 中稳定采集，就不要把它放进 SLO 计算。
3.5 常见误区与避坑指南
- 误区一：所有服务都用同一套 SLI。实际上，数据库和批处理的 SLI 与 HTTP API 完全不同。
- 误区二：只选延迟，忽略错误率。延迟再低，如果错误率飙升，用户体验依然极差。
- 误区三：SLI 粒度过细。每个 endpoint 都设独立 SLI 会导致告警风暴，建议按功能模块聚合。
- 误区四：忽略吞吐量。当流量骤降时，延迟和错误率可能正常，但服务实际上已不可用。
最佳实践：每个服务至少包含 1 个延迟指标和 1 个错误率指标。吞吐量作为辅助指标，用于容量规划和异常检测。
3.6 本章小结
SLI 指标设计是 SLO 工程的第一步，也是最关键的一步。记住三个核心原则：
- 因服务而异：HTTP API 重延迟，数据库重慢查询，批处理重完成时间。
- 少而精：每个服务 2~3 个 SLI，避免指标泛滥。
- 可测量：确保 Prometheus 能稳定采集，且 cardinality 可控。