1. SLO与误差预算基础:SLO定义、SLI指标、误差预算概念、为什么需要误差预算告警
1.1 从可靠性度量到服务等级目标
在站点可靠性工程(SRE)体系中,服务等级目标(SLO)是衡量系统可靠性的核心契约。它不是一个简单的“可用性百分比”,而是基于用户真实体验的量化承诺。要理解SLO,必须先厘清三个基础概念:SLI、SLO与误差预算。
| 术语 | 全称 | 核心定义 | 示例 |
|---|---|---|---|
| SLI | Service Level Indicator | 服务等级指标,是系统某一维度(如延迟、错误率、吞吐量)的原始测量值 | 请求延迟 P99 = 200ms |
| SLO | Service Level Objective | 服务等级目标,是SLI的目标阈值或范围,代表“好事件”应达到的比例 | 99.9% 的请求延迟 ≤ 200ms |
| 误差预算 | Error Budget | 误差预算 = 1 - SLO,代表在SLO周期内允许的不可用时间或失败次数 | 月度 99.9% SLO 允许 43.2 分钟不可用 |
关键认知:SLO 不是“系统能达到什么水平”,而是“用户能接受什么水平”。误差预算则是将可靠性从“追求”转化为“可管理资源”的关键桥梁。
1.2 SLI指标:定义“好事件”的测量标准
SLI是SLO的基石。一个有效的SLI必须满足可测量、可对比、与用户体验强相关三个条件。在Prometheus生态中,SLI通常通过Histogram、Counter或Gauge指标类型来采集。
常见的SLI分类与Prometheus采集方式:
- 请求延迟(Latency):使用
histogram_quantile计算 P50/P90/P99 延迟。例如:histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) - 错误率(Error Rate):使用
rate()计算错误请求占总请求的比例。例如:rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) - 吞吐量(Throughput):使用
rate()或irate()计算每秒请求数。 - 饱和度(Saturation):使用
Gauge测量资源使用率,如 CPU 使用率、队列深度。
SLI 设计原则:优先选择“用户可见”的指标。例如,对于 Web 服务,请求延迟和错误率是比 CPU 使用率更直接的 SLI。CPU 使用率可以作为“饱和度”指标辅助判断,但不建议直接作为 SLO 的 SLI。
1.3 误差预算:可靠性的“预算管理”思维
误差预算将可靠性从“技术指标”转化为“业务资源”。其核心公式为:
Error Budget = 1 - SLO
例如:
SLO = 99.9% → Error Budget = 0.1%
月度总时间 = 30天 × 24小时 × 60分钟 = 43200 分钟
允许不可用时间 = 43200 × 0.1% = 43.2 分钟
误差预算的消耗与补充机制:
- 消耗:每次 SLI 未达到 SLO 阈值(即“坏事件”),都会消耗误差预算。
- 补充:在每个 SLO 周期(通常为 30 天)结束时,误差预算重置为满额。
- 管理意义:当误差预算充足时,团队可以更积极地发布新功能;当预算紧张时,应优先投入稳定性工作。
1.4 为什么需要误差预算告警?
传统的告警策略(如“CPU > 90%”或“错误率 > 5%”)存在两个根本问题:阈值静态化和缺乏业务语义。误差预算告警则从根本上改变了这一模式。
传统告警 vs 误差预算告警对比:
| 维度 | 传统告警 | 误差预算告警 |
|---|---|---|
| 阈值来源 | 运维经验或硬件极限 | 从 SLO 推导,与用户承诺绑定 |
| 告警频率 | 容易产生告警风暴,短时抖动即触发 | 基于消耗速率,容忍短时抖动 |
| 业务关联 | 低,只反映系统状态 | 高,直接反映用户满意度风险 |
| 降噪能力 | 弱,需要大量静默规则 | 强,通过预算窗口自然过滤噪音 |
| 行动指引 | “修复指标” | “保护剩余预算”或“暂停发布” |
常见误区:不要将误差预算告警等同于“SLO 违约告警”。误差预算告警是在预算消耗速率过快时提前预警,而不是等到 SLO 已经违约才告警。后者往往为时已晚。
误差预算告警的核心价值在于:
- 将告警与业务风险对齐:告警不再是“系统有点问题”,而是“用户满意度正在被侵蚀”。
- 提供自然的告警降噪:只要误差预算充足,短时的指标毛刺不会触发告警,大幅减少无效告警。
- 支持发布决策:当误差预算消耗过快时,告警可以作为“停止发布”或“回滚”的自动化触发条件。
- 量化可靠性投资:通过跟踪误差预算消耗趋势,可以量化每次故障对用户的影响,指导稳定性投入优先级。
1.5 误差预算告警在Prometheus中的实现思路
在Prometheus中,误差预算告警通常基于SLI的燃烧速率(Burn Rate)来构建。燃烧速率表示误差预算消耗的速度,其计算公式为:
Burn Rate = (1 - 实际SLI) / (1 - SLO)
例如:
SLO = 99.9%(允许错误率 0.1%)
实际错误率 = 0.5%
Burn Rate = 0.5% / 0.1% = 5x
含义:误差预算消耗速度是预期的 5 倍。
基于燃烧速率的告警规则示例(PromQL):
# 计算过去 1 小时的燃烧速率
groups:
- name: error_budget_alerts
rules:
- alert: HighErrorBudgetBurnRate
expr: |
(
1 - (
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
)
) / (1 - 0.999) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "误差预算消耗速率过高(当前 {{ $value }}x)"
description: "过去 1 小时误差预算消耗速率为预期的 {{ $value }} 倍,请关注。"
核心要点:误差预算告警的阈值不是固定的百分比,而是燃烧速率。通过设置不同的燃烧速率阈值(如 2x、5x、10x)和不同的时间窗口(如 1h、6h、24h),可以实现多级告警,既保证及时性,又避免噪音。