4. 数据采集链路全景：从目标服务 → Exporter → Prometheus → 台账计算引擎的完整数据流
理解误差预算台账的生成，必须首先掌握数据从产生到最终聚合的完整链路。任何一个环节的异常（如Exporter挂起、Prometheus抓取超时、数据缺失）都会直接污染台账的准确性。本节将链路拆解为四个核心阶段，并逐一分析其数据形态与风险点。
4.1 链路四阶段总览
数据流从目标服务的内部指标出发，经过Exporter的格式转换、Prometheus的时序存储，最终进入台账计算引擎进行SLO聚合。下表概括了每个阶段的输入、输出与关键组件：
| 阶段 | 输入 | 处理组件 | 输出 | 典型协议/格式 |
|---|---|---|---|---|
| 1. 目标服务 | 应用内部状态（请求数、延迟、错误数） | 应用代码 / 中间件 | 原始指标（Counter、Histogram、Gauge） | 应用自定义埋点 / 框架自动采集 |
| 2. Exporter | 原始指标（通过JMX、HTTP、DB查询等获取） | Exporter进程（如node_exporter、custom_exporter） | Prometheus兼容的Metrics端点（/metrics） | Prometheus Exposition Format（文本/Protobuf） |
| 3. Prometheus | Exporter暴露的/metrics数据 | Prometheus Server（抓取、存储、查询） | 时序数据库（TSDB）中的时间序列 | PromQL查询结果 / Remote Write |
| 4. 台账计算引擎 | Prometheus中的时序数据（通过PromQL或API） | 台账服务（如自研计算器、Grafana、Thanos） | 误差预算台账（SLO达成率、燃烧速率、剩余预算） | JSON / 内部RPC / 数据库记录 |
4.2 阶段一：目标服务 → Exporter（数据源头的暴露）
目标服务本身并不直接暴露Prometheus格式的指标。它通过内部埋点（如Micrometer、Prometheus Client Library）记录请求总数、错误总数、延迟分布等原始数据。Exporter的作用是“桥接”：从目标服务的内部状态（如JMX MBeans、HTTP端点、日志文件、系统调用）中读取这些原始数据，并将其转换为Prometheus能够抓取的格式。
- 数据形态： 目标服务内部通常是Counter（只增不减）、Histogram（分桶计数）、Gauge（可增可减）。
- 风险点： Exporter与目标服务之间的连接中断、Exporter进程OOM、目标服务本身埋点缺失（如漏记错误请求）。
- 典型场景： Java应用通过JMX Exporter暴露JVM指标；MySQL通过mysqld_exporter暴露查询延迟。
4.3 阶段二：Exporter → Prometheus（抓取与存储）
Prometheus Server按照配置的scrape_interval（通常为15s或30s）主动拉取Exporter的/metrics端点。这是链路中最关键的“心跳”环节。如果抓取失败（超时、返回非200状态码、数据格式错误），Prometheus会记录一次up == 0的告警，但不会重试该周期的数据。
# 典型的Prometheus抓取配置片段
scrape_configs:
- job_name: 'my-app'
scrape_interval: 15s
scrape_timeout: 10s
metrics_path: '/metrics'
static_configs:
- targets: ['192.168.1.100:8080']- 数据形态： 时间序列（metric_name + labels + timestamp + value）。
- 风险点： 抓取超时（scrape_timeout < 实际响应时间）、目标服务重启导致时间戳跳跃、标签基数爆炸导致存储压力。
- 影响台账： 一次抓取失败意味着该时间窗口内缺失一个数据点。对于基于
rate()计算的SLO，缺失点会导致该周期内请求总数被低估，进而高估误差预算。
4.4 阶段三：Prometheus → 台账计算引擎（数据查询与聚合）
台账计算引擎通过PromQL查询Prometheus中的原始时序数据，执行SLO相关的聚合计算。例如，计算过去30天内的总请求数和总错误数，然后计算SLO达成率。这个阶段的数据流是“拉取”或“推送”两种模式：
- 拉取模式： 台账引擎定期执行PromQL查询（如
sum(rate(http_requests_total{job="my-app"}[5m]))）。 - 推送模式： Prometheus通过Remote Write将数据推送到台账引擎的中间存储（如Kafka、VictoriaMetrics）。
rate()、increase()函数对数据缺失非常敏感——连续缺失两个抓取周期会导致函数返回0或异常值。
4.5 完整数据流SVG架构图
下图展示了从目标服务到台账计算引擎的完整数据流，并标注了每个环节的关键指标与潜在故障点：
4.6 数据流中的关键指标与监控矩阵
为了快速定位采集链路中的异常，SRE团队需要建立针对每个环节的监控指标矩阵。下表列出了每个阶段的核心监控指标及其对误差预算的直接影响：
| 链路阶段 | 监控指标 | 正常范围 | 异常对台账的影响 |
|---|---|---|---|
| 目标服务 | http_requests_total 增长率 |
与历史基线偏差 < 20% | 请求数低估 → 预算高估 |
| Exporter | up 指标值 |
恒为 1 | Exporter宕机 → 数据完全缺失 → 预算计算中断 |
| Prometheus | scrape_samples_scraped |
与预期样本数一致 | 样本数减少 → 统计偏差 → 预算不准确 |
| 台账引擎 | slo_budget_remaining |
大于 0 | 计算错误 → 预算值异常跳变 |
alerting规则，当up == 0持续超过2个抓取周期时立即告警。同时，在台账计算引擎中实现“数据完整性校验”：如果最近5分钟内的数据点缺失率超过10%，则暂停预算更新并标记台账为“数据不可靠”状态。
4.7 数据流异常对误差预算的传导效应
为了更直观地理解链路异常如何影响最终台账，下图展示了一个典型的“Exporter短暂宕机”场景，以及该异常如何通过数据流逐级传导至误差预算：