3. SLI指标设计：四大黄金信号
在SRE实践中，SLI（Service Level Indicator，服务等级指标）是衡量服务行为的具体量化指标。Google SRE团队总结出四大黄金信号——延迟、流量、错误、饱和度，这四类指标能够从不同维度全面刻画服务的健康状态。本章将深入解析每个信号的含义、采集方式，并给出为不同服务定义SLI的实战方法。
核心原则：SLI必须与用户体验强相关。一个SLI如果无法反映用户实际感受到的服务质量，就不应被选入SLO体系。
3.1 四大黄金信号详解
| 黄金信号 | 定义 | 典型指标 | 采集方式 |
|---|---|---|---|
| 延迟 (Latency) | 请求从发出到收到响应所花费的时间 | p50/p90/p99 响应时间 | Prometheus Histogram/Summary |
| 流量 (Traffic) | 系统承载的请求量级或吞吐量 | QPS、RPS、并发连接数 | Prometheus Counter/Gauge |
| 错误 (Errors) | 请求失败的比率或数量 | HTTP 5xx率、超时率、异常率 | Prometheus Counter + 标签过滤 |
| 饱和度 (Saturation) | 系统资源被消耗的程度，越接近极限越危险 | CPU使用率、内存占用、磁盘IO、连接池使用率 | Prometheus Gauge + 利用率计算 |
实战建议：四大黄金信号并非必须全部使用。对于无状态API服务，延迟和错误是最关键的SLI；对于数据库或消息队列，饱和度和延迟往往更能反映真实风险。
3.2 四大黄金信号关联架构
下图展示了四大黄金信号在典型微服务架构中的采集位置与关联关系。每个信号从不同层面反映服务状态，共同构成完整的可观测性视图。
3.3 为不同服务定义SLI
不同服务类型对四大黄金信号的敏感度不同。以下给出三类典型服务的SLI定义模板，可直接用于Prometheus指标配置。
3.3.1 HTTP API服务
| 黄金信号 | SLI定义 | PromQL表达式示例 |
|---|---|---|
| 延迟 | 过去5分钟内，p99响应时间 ≤ 500ms 的请求占比 | histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) |
| 流量 | 过去1分钟内，每秒请求数（QPS） | sum(rate(http_requests_total[1m])) |
| 错误 | 过去5分钟内，HTTP 5xx响应占比 ≤ 1% | sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) |
| 饱和度 | 过去1分钟内，CPU使用率 ≤ 80% | avg(rate(node_cpu_seconds_total{mode="idle"}[1m])) → 计算使用率 |
3.3.2 数据库服务（以MySQL为例）
| 黄金信号 | SLI定义 | PromQL表达式示例 |
|---|---|---|
| 延迟 | 过去5分钟内，p99查询延迟 ≤ 100ms | histogram_quantile(0.99, sum(rate(mysql_queries_duration_seconds_bucket[5m])) by (le)) |
| 流量 | 过去1分钟内，每秒查询数（QPS） | sum(rate(mysql_global_status_questions[1m])) |
| 错误 | 过去5分钟内，查询失败率 ≤ 0.1% | sum(rate(mysql_errors_total[5m])) / sum(rate(mysql_queries_total[5m])) |
| 饱和度 | 连接数使用率 ≤ 80% | mysql_global_status_threads_connected / mysql_global_variables_max_connections |
3.3.3 消息队列服务（以Kafka为例）
| 黄金信号 | SLI定义 | PromQL表达式示例 |
|---|---|---|
| 延迟 | 过去5分钟内，消息端到端延迟 p99 ≤ 2s | histogram_quantile(0.99, sum(rate(kafka_consumer_lag_seconds_bucket[5m])) by (le)) |
| 流量 | 过去1分钟内，每秒消息生产量 | sum(rate(kafka_topic_messages_in_total[1m])) |
| 错误 | 过去5分钟内，消息生产/消费失败率 ≤ 0.5% | sum(rate(kafka_request_errors_total[5m])) / sum(rate(kafka_requests_total[5m])) |
| 饱和度 | 磁盘使用率 ≤ 85% | kafka_log_dir_size_bytes / kafka_log_dir_capacity_bytes |
避坑指南：不要将基础设施指标直接作为服务SLI。例如，CPU使用率是饱和度信号，但不应作为API服务的核心SLI——用户只关心请求是否成功和快速，不关心CPU是否繁忙。基础设施指标应作为辅助诊断信号，而非SLO承诺对象。
3.4 SLI定义流程
为服务定义SLI时，建议遵循以下四步流程：
- 识别用户旅程：确定用户与服务的核心交互路径（如登录、搜索、下单）。
- 选择黄金信号：根据服务类型，从四大信号中选出2-3个最关键的维度。
- 确定阈值与窗口：结合历史数据和业务容忍度，设定合理的SLI阈值（如p99延迟≤200ms）。
- 验证可观测性：确保Prometheus已正确采集相关指标，且PromQL表达式能准确计算SLI。
3.5 SLI定义决策树
下图帮助快速判断不同服务应优先关注哪些黄金信号：
3.6 SLI定义最佳实践
- 从用户视角出发：SLI应衡量用户实际感知到的服务质量，而非内部组件状态。例如，用“API响应时间”而非“CPU空闲时间”。
- 使用分位数而非平均值：平均值会掩盖长尾问题，p99或p95能更真实反映用户体验。
- 定义明确的成功标准：错误SLI需要明确“什么是错误”——HTTP 5xx、超时、业务错误码？不同错误类型应分开统计。
- 设置合理的窗口期：SLI计算窗口通常为5-10分钟，太短容易抖动，太长会掩盖瞬时故障。
- 避免指标爆炸：每个服务选择2-3个核心SLI即可，过多的SLI会增加运维复杂度和告警噪音。
快速上手：对于新接入Prometheus的服务，建议先采集所有四大黄金信号的原始指标，运行1-2周后根据数据分布确定合理的SLI阈值，再逐步收敛到核心SLI集合。