Exporter指标采集链路故障排查误差预算台账数据不准 - 第3节
3.1 误差预算（Error Budget）核心概念
误差预算（Error Budget）是 SLO（服务等级目标）体系中的核心量化工具，它将抽象的“可用性”或“可靠性”转化为可度量的、可消耗的“预算额度”。其基本公式为：
Error Budget = 1 - SLO（以百分比表示的时间窗口内）例如，若某服务的月度 SLO 为 99.9%，则其月度误差预算为 0.1%。这意味着在一个月（约 43200 分钟）内，该服务最多允许 43.2 分钟的不达标时间。一旦消耗完预算，团队应停止发布新功能，优先投入可靠性修复。
核心观点： 误差预算将“可靠性”从不可量化的目标转变为可管理的资源，是 DevOps 中“平衡创新与稳定”的决策依据。
3.1.1 误差预算的消耗与恢复机制
- 消耗源： 任何导致服务违反 SLO 的事件（如延迟升高、错误率增加、可用性下降）。
- 恢复机制： 时间窗口滚动。随着时间推移，旧的消耗数据会移出窗口，预算自动恢复。
- 决策阈值： 通常设定预算消耗 50% 为警告线，100% 为冻结线（停止发布）。
3.2 台账（Ledger）在 SLO 管理中的作用
台账（Ledger）是误差预算的“会计账簿”，它记录每一次 SLO 事件的详细明细，包括时间戳、指标值、违反时长、影响范围等。台账是 SLO 审计、故障复盘、预算校准的基础。
| 台账功能 | 详细说明 | 典型字段 |
|---|---|---|
| 事件记录 | 精确记录每次 SLO 违反的起止时间、持续时长 | event_id, start_time, end_time, duration_sec |
| 指标溯源 | 关联违反时的原始指标值（延迟、错误率等） | latency_p99, error_rate, request_count |
| 预算扣减 | 计算本次事件消耗的预算额度 | budget_consumed, remaining_budget |
| 审计追溯 | 提供不可篡改的审计日志，用于合规与复盘 | audit_hash, operator, system_version |
实践建议： 台账应至少保留 3 个完整滚动窗口的数据（如月度 SLO 保留 3 个月），以便进行趋势分析和预算校准。
3.3 为什么台账数据会不准？
在实际生产环境中，台账数据不准是普遍现象，主要原因可归纳为以下四类：
3.3.1 采集链路误差
- Exporter 采集偏差： 指标采集周期（scrape_interval）与 SLO 计算窗口不匹配，导致短时突发被遗漏。
- 时间戳对齐问题： 多实例时间不同步，导致事件起止时间错位。
- 指标聚合丢失： 在 Prometheus 等系统中，聚合操作（如 avg、max）会抹除部分细节。
3.3.2 计算逻辑错误
- SLO 定义歧义： 滚动窗口 vs 固定窗口、日历月 vs 滚动月，不同定义导致预算差异。
- 预算扣减算法： 按事件时长扣减 vs 按请求比例扣减，结果可能相差数倍。
- 边界条件处理： 窗口边界处的部分事件是否计入？跨窗口事件如何分割？
3.3.3 数据存储与同步问题
- 写入丢失： 高并发下台账写入失败，导致事件记录缺失。
- 数据重复： 重试机制导致同一事件被记录多次。
- 存储延迟： 异步写入导致台账更新滞后，实时预算显示不准。
3.3.4 人为操作与配置错误
- Exporter 配置变更： 修改 scrape_interval 或 metric_relabel_configs 后未同步更新台账计算逻辑。
- SLO 目标调整： 调整 SLO 值后，历史台账未重新计算。
- 手动干预： 运维人员手动修改台账数据，导致与原始指标不一致。
常见误区： 很多团队只关注 SLO 仪表盘上的“当前预算百分比”，而忽略了台账明细的准确性。一旦台账不准，所有基于预算的决策（如是否发布）都可能出错。
3.4 误差预算与台账的关系图
下图展示了从指标采集到台账生成、再到预算消耗的完整链路，以及各环节可能引入误差的位置：
3.5 台账数据不准的典型表现
| 表现现象 | 可能原因 | 影响范围 |
|---|---|---|
| 预算消耗速度异常 | 采集周期过长导致突发漏采 | 短期预算失真 |
| 台账与原始指标对不上 | 聚合逻辑或扣减算法不一致 | 审计无法通过 |
| 跨窗口预算跳跃 | 窗口边界事件处理逻辑错误 | 预算连续性破坏 |
| 历史台账突然变化 | 配置变更后未重新计算历史数据 | 趋势分析失效 |
校准原则： 台账数据必须与原始指标数据保持可追溯的对应关系。任何台账与原始指标不一致的情况，都应视为数据质量问题，需要立即排查。