2. Prometheus 采集链路全景：从 Exporter 到 Alertmanager 的完整数据流

在排查误差预算台账数据不准之前，必须对 Prometheus 采集链路有一个全局认知。误差预算的计算依赖 SLI 指标的准确采集与传递，链路中任何一个环节出现数据丢失、延迟或精度损失，都会直接导致台账失真。本章将完整拆解从 Exporter 到 Alertmanager 的端到端数据流，并逐一标注关键组件及其职责。

2.1 链路全景总览

Prometheus 采集链路可划分为四个核心阶段：指标暴露 → 指标抓取 → 指标存储与处理 → 告警与消费。下图展示了完整的端到端数据流，以及每个阶段的关键组件。

2.2 各环节关键组件与职责

以下表格详细列出每个阶段的核心组件、数据流向以及常见的台账不准风险点。

阶段	关键组件	核心职责	台账不准风险点
指标暴露	Exporter（node_exporter / blackbox_exporter / custom_exporter） 应用自身 /metrics 端点	将系统、应用或业务指标转换为 Prometheus 可抓取的 HTTP /metrics 格式	指标命名错误、标签缺失、数据类型不匹配、采样精度不足、Exporter 进程重启导致计数器重置
指标抓取	Prometheus Server（scrape manager）	根据 scrape_config 定时拉取目标端点，解析指标并传递给存储层	抓取超时、抓取间隔不一致、目标不可达、样本重复或丢失、relabel 配置错误导致标签丢失
存储与处理	TSDB（本地存储） Recording Rules / Alerting Rules	存储时间序列数据；通过 PromQL 预计算聚合指标或触发告警	数据过期策略（retention）导致历史数据丢失、Recording Rules 计算周期与抓取周期不同步、聚合函数精度损失
告警与消费	Alertmanager Remote Write / API 消费端	接收告警并去重、分组、静默、路由；将指标转发给外部系统	告警延迟、分组规则导致告警合并丢失细节、Remote Write 写入失败、消费端数据口径不一致

2.3 数据流详细分解

为了更清晰地理解数据在链路中的传递路径，下面按步骤拆解一次完整的指标采集流程。

1. Exporter 暴露指标：Exporter 在指定端口（如 9100）提供 HTTP 服务，响应 /metrics 请求，返回 Prometheus 文本格式的指标数据。
2. Prometheus Server 发起抓取：根据 scrape_config 中定义的 job_name、targets、scrape_interval，Prometheus 的 scrape manager 向目标发起 HTTP GET 请求。
3. 数据解析与 relabel：Prometheus 解析返回的文本，应用 relabel_configs 对标签进行增删改，然后写入内存中的 head block。
4. TSDB 持久化：内存中的数据按 block 格式写入磁盘，并定期压缩（compaction）以优化查询性能。
5. Recording Rules 预计算：Prometheus 按 evaluation_interval 执行 Recording Rules，将预聚合结果写入新的时间序列。
6. Alerting Rules 评估：Prometheus 评估 Alerting Rules，当条件满足时生成告警并推送给 Alertmanager。
7. Alertmanager 处理告警：Alertmanager 对告警进行去重、分组、静默，最终通过配置的 receiver（如 Email、Webhook）发送通知。

2.4 关键组件配置示例

以下展示一个典型的 Prometheus 采集链路配置片段，包含 Exporter 暴露、Prometheus 抓取、Recording Rules 预计算和 Alertmanager 路由。

# prometheus.yml 核心配置
global:
  scrape_interval: 15s
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance
        regex: '(.*):.*'
        replacement: '$1'

rule_files:
  - 'rules/recording_rules.yml'
  - 'rules/alerting_rules.yml'

# recording_rules.yml 示例
groups:
  - name: sli_errors
    interval: 1m
    rules:
      - record: job:sli_error_budget:ratio_5m
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))

# alertmanager.yml 核心配置
route:
  receiver: 'sre-team'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
receivers:
  - name: 'sre-team'
    webhook_configs:
      - url: 'http://webhook.example.com/alert'

2.5 链路中各环节的时序关系

为了直观展示数据在时间轴上的传递关系，下图以 15s 抓取间隔、30s 评估间隔为例，绘制了从 Exporter 到 Alertmanager 的时序交互。

2.6 链路排查的关键指标

在排查误差预算台账数据不准时，以下 Prometheus 自身指标可以帮助快速定位链路中的异常环节。

• prometheus_target_scrapes_total：抓取总次数，结合 prometheus_target_scrapes_exceeded_sample_limit_total 判断是否因样本限制导致数据丢失。
• prometheus_target_scrape_duration_seconds：抓取耗时，若接近 scrape_timeout 则可能超时。
• prometheus_tsdb_head_samples_appended_total：TSDB head block 追加的样本数，用于判断数据是否成功写入。
• prometheus_rule_evaluation_duration_seconds：规则评估耗时，若持续偏高则可能影响台账计算周期。
• alertmanager_alerts_received_total：Alertmanager 接收的告警总数，用于判断告警是否成功传递。