4. SLO 作业模板核心字段：服务名称、SLI指标、目标阈值、时间窗口、燃烧速率
一个标准化的 SLO 作业模板是连接服务定义与告警策略的桥梁。模板中的每个字段都直接决定了 SLO 的计算方式、合规性判定以及告警的触发时机。本章将逐一拆解五个核心字段的定义、填写规范及其在 Prometheus 告警联动中的实际映射关系。
核心认知： SLO 模板不是静态的文档，而是一份可执行的“监控契约”。字段的精确度直接决定了告警的准确性和运维效率。
4.1 核心字段总览
下表列出了 SLO 作业模板的五个核心字段及其在 Prometheus 中的对应关系，帮助快速建立全局认知。
| 字段名称 | 定义 | Prometheus 映射 | 示例值 |
|---|---|---|---|
| 服务名称 | 被监控服务的唯一标识 | service 标签 |
api-gateway |
| SLI 指标 | 衡量服务质量的具体指标表达式 | PromQL 查询语句 | http_requests_total{status=~"5.."} |
| 目标阈值 | SLI 必须达到的合规百分比 | 告警规则中的 threshold |
99.9% |
| 时间窗口 | 评估 SLO 合规性的回溯周期 | PromQL 中的 range vector |
30d |
| 燃烧速率 | 错误预算消耗的速度阈值 | 告警规则中的 burnrate |
14.4x (1小时耗尽30天预算) |
4.2 字段详解与填写规范
4.2.1 服务名称
服务名称是 SLO 模板的“主键”。在微服务架构中，它必须与 Prometheus 的 service 或 job 标签严格一致，确保告警规则能正确匹配到目标服务。
- 规范： 使用小写字母、连字符，避免下划线和特殊字符。
- 示例：
user-service、order-processing。 - 联动： 在 Prometheus 告警规则中，通过
service="user-service"进行标签选择。
4.2.2 SLI 指标
SLI 指标是 SLO 的“测量仪”。它必须是一个可量化的 PromQL 表达式，通常分为“好事件”和“总事件”两部分。
- 请求成功率：
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])) - 请求延迟：
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m])) by (le))
避坑指南： SLI 表达式必须保证分母不为零。对于低频服务，建议使用
avg_over_time 或增加最小周期约束，避免因数据缺失导致 SLO 计算异常。
4.2.3 目标阈值
目标阈值定义了“好”与“坏”的分界线。常见的阈值设定为 99.9%（三个9）、99.99%（四个9）。
- 格式： 使用百分比小数，如
0.999代表 99.9%。 - 影响： 阈值越高，错误预算越少，对燃烧速率的敏感度越高。
4.2.4 时间窗口
时间窗口决定了 SLO 的“考核周期”。Prometheus 通常使用 30d 作为标准窗口，与错误预算的消耗周期对齐。
- 常见值：
7d（快速迭代）、30d（标准稳定）、90d（长期合规）。 - 联动： 在 PromQL 中，时间窗口通过
[30d]范围向量实现，例如avg_over_time(sli:success_rate[30d])。
4.2.5 燃烧速率
燃烧速率是告警触发的“加速器”。它定义了错误预算消耗的速度，是多窗口、多燃烧速率告警策略的核心。
- 计算： 燃烧速率 = (1 - 目标阈值) / (时间窗口内允许的错误预算比例)。
- 示例： 对于 99.9% 的 SLO，30 天总错误预算为 43.2 分钟。如果希望在 1 小时内触发告警，则燃烧速率为 43.2 / 1 = 43.2x。
4.3 字段联动关系：从模板到告警
下图展示了 SLO 模板字段如何映射到 Prometheus 告警规则中，形成完整的告警链路。
4.4 燃烧速率计算实战
燃烧速率是告警策略中最关键也最容易出错的字段。下面通过一个具体案例演示其计算过程。
案例： 某服务 SLO 目标为 99.9%，时间窗口为 30 天。我们希望当错误预算可能在 1 小时内耗尽时触发 P0 告警。
- 计算总错误预算： 30 天 = 43200 分钟。允许的错误时间 = 43200 * (1 - 0.999) = 43.2 分钟。
- 确定告警窗口： 我们希望 1 小时内耗尽，即告警窗口 = 60 分钟。
- 计算燃烧速率： 燃烧速率 = 总错误预算 / 告警窗口 = 43.2 / 1 = 43.2x。
- 生成告警规则： 当过去 1 小时的燃烧速率超过 43.2 时，触发告警。
对应的 Prometheus 告警规则片段如下：
groups:
- name: slo_alerts
rules:
- alert: SLOBurnRateHigh
expr: |
(
(1 - (sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h]))))
/ (1 - 0.999)
) > 43.2
for: 5m
labels:
severity: critical
annotations:
summary: "SLO 燃烧速率过高 ({{ $value | humanizePercentage }})"
description: "服务 {{ $labels.service }} 的 SLO 错误预算可能在 1 小时内耗尽。"4.5 多窗口燃烧速率策略
单一燃烧速率容易产生误报。生产环境通常采用多窗口策略，通过不同时间窗口的组合来平衡告警的及时性与准确性。
| 告警级别 | 时间窗口 | 燃烧速率 | 触发条件 | 响应时间 |
|---|---|---|---|---|
| P0 (Critical) | 1h | 43.2x | 1小时内耗尽预算 | 立即响应 |
| P1 (Warning) | 6h | 7.2x | 6小时内耗尽预算 | 15分钟 |
| P2 (Info) | 3d | 1.2x | 3天内耗尽预算 | 1小时 |
最佳实践： 建议为每个 SLO 配置至少 3 个燃烧速率告警（P0/P1/P2），覆盖从“即将发生”到“正在发生”的全场景。P0 用于即时响应，P2 用于趋势预警。
通过精确配置 SLO 模板的五个核心字段，团队可以将服务等级目标从文档转化为可执行、可告警的监控体系，实现从“被动响应”到“主动预防”的运维模式转变。