2. SLI 设计原则：如何选择关键业务指标、SLI 的采集方式与数据源
SLI（Service Level Indicator）是 SLO 体系的基石。错误的 SLI 选择会导致 SLO 无法反映真实用户体验，甚至误导容量压测的决策。本节聚焦于 SLI 的选取原则、采集方式与数据源设计，确保指标既“可测量”又“有意义”。
2.1 关键业务指标的选择原则
选择 SLI 时，必须遵循以下四项核心原则，避免陷入“监控所有指标”的陷阱：
| 原则 | 说明 | 反例 |
|---|---|---|
| 用户视角优先 | SLI 必须反映用户端可感知的服务质量，而非内部组件健康度。 | 用 CPU 使用率作为核心 SLI，而非请求延迟 |
| 可测量性 | 指标必须能被精确采集，且采集成本可控。 | 选择“用户满意度”这种无法直接量化的指标 |
| 覆盖率 | SLI 应覆盖服务的关键路径，避免遗漏核心链路。 | 只监控首页，忽略下单接口 |
| 可操作性 | 当 SLI 告警时，团队能明确知道下一步该做什么。 | “系统稳定性”这种过于宽泛的指标 |
实践建议： 优先从“黄金信号”（延迟、流量、错误、饱和度）中选取 2-3 个作为核心 SLI。对于容量压测场景，延迟（Latency） 和 错误率（Error Rate） 是最具代表性的水位指标。
2.2 SLI 的采集方式与数据源架构
SLI 的采集方式决定了数据的准确性与实时性。常见的采集方式分为客户端埋点、服务端日志、中间件指标三大类。下图展示了典型的数据源架构：
2.3 三种采集方式的对比与选型
不同的采集方式适用于不同的场景，下表从准确性、延迟、覆盖范围三个维度进行对比：
| 采集方式 | 准确性 | 采集延迟 | 覆盖范围 | 典型工具 |
|---|---|---|---|---|
| 客户端埋点（RUM） | 高（真实用户数据） | 分钟级 | 前端全量用户 | Web Vitals、自研 SDK |
| 服务端日志 | 中（受采样率影响） | 秒级 | 后端请求链路 | ELK、Loki、自研日志 |
| 中间件指标 | 高（系统级精确） | 秒级 | 基础设施与中间件 | Prometheus、Micrometer |
容量压测场景下的推荐组合：
- 延迟 SLI： 优先使用服务端日志采集 P99 延迟，辅以客户端 RUM 验证端到端体验。
- 错误率 SLI： 以服务端日志的 HTTP 状态码统计为主，中间件指标（如 DB 连接池错误）作为补充。
- 饱和度 SLI： 依赖中间件指标（CPU、内存、连接数），用于判断系统是否达到压测水位。
2.4 数据源设计的关键考量
在构建 SLI 数据源时，需要关注以下三个关键点：
- 采样策略： 高并发场景下全量采集成本过高，建议采用自适应采样（如根据请求延迟动态调整采样率），确保长尾请求不被遗漏。
- 时间窗口对齐： 不同数据源的时间戳精度可能不一致（如客户端毫秒级 vs 服务端秒级），需要在聚合层做对齐处理，避免计算偏差。
- 标签标准化： 所有采集点必须携带统一的元数据标签（如服务名、版本、机房、压测标记），便于后续按维度聚合与下钻分析。
常见陷阱： 不要将“服务端平均延迟”作为 SLI。平均延迟会掩盖长尾问题，导致容量压测时低估真实负载下的性能劣化。始终使用 P95 / P99 延迟 作为核心指标。
2.5 从 SLI 到 SLO 的映射关系
选择好 SLI 后，需要将其转化为可量化的 SLO 目标。下图展示了 SLI 与 SLO 的映射关系：
在实际容量压测中，SLI 的采集与 SLO 的制定是迭代过程。建议先基于历史数据设定初始阈值，再通过压测验证阈值是否合理，最终形成稳定的 SLI → SLO 映射关系。