2. 指标采集链路全景：从目标系统到 Prometheus Server 的完整数据流
在排查指标采集故障或校准误差预算台账之前，必须对采集链路中每一个环节的数据形态、传输协议和时序逻辑有精确理解。本节将拆解从目标系统内部指标产生，到 Prometheus Server 完成数据持久化的完整路径，并重点剖析 Exporter 暴露端口与 /metrics 端点的工作机制，以及 Server 端抓取（Scrape）的详细流程。
2.1 完整数据流：四阶段模型
指标数据从产生到入库，经历四个逻辑阶段。每个阶段都可能引入数据丢失、延迟或精度偏差，是故障排查与误差校准的关键检查点。
2.2 Exporter 暴露端口与 /metrics 端点
Exporter 是目标系统与 Prometheus Server 之间的“翻译层”。它通过一个独立的 HTTP 服务将内部状态转换为 Prometheus 可识别的文本格式。
2.2.1 端口绑定与监听
- 默认端口： 每个官方 Exporter 有约定端口（如 node_exporter 使用
:9100，blackbox_exporter 使用:9115）。 - 自定义端口： 通过启动参数
--web.listen-address=":9200"可修改。 - 多实例部署： 同一主机可运行多个 Exporter 实例，但端口必须唯一，否则端口冲突导致启动失败。
2.2.2 /metrics 端点响应格式
Prometheus Server 通过 HTTP GET 请求 http://<exporter_host>:<port>/metrics 获取数据。响应体为纯文本，遵循以下结构：
# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 283910.45
node_cpu_seconds_total{cpu="0",mode="system"} 8472.13
# HELP node_memory_MemTotal_bytes Memory information field MemTotal_bytes.
# TYPE node_memory_MemTotal_bytes gauge
node_memory_MemTotal_bytes 16625385472
| 行类型 | 格式 | 说明 |
|---|---|---|
| HELP | # HELP <metric_name> <doc_string> |
指标描述，可选，Prometheus 解析时忽略 |
| TYPE | # TYPE <metric_name> <metric_type> |
声明指标类型（counter / gauge / histogram / summary） |
| 样本行 | <metric_name>{<labels>} <value> [<timestamp>] |
实际数据点，时间戳可选（默认使用 Server 接收时间） |
2.3 抓取（Scrape）机制详解
抓取是 Prometheus Server 主动发起的 HTTP 请求，是采集链路中控制逻辑最复杂的环节。理解其内部状态机，是定位“抓取失败”和“数据空洞”的基础。
2.3.1 抓取生命周期
- 调度触发： 基于
scrape_interval（默认 15s）定时器触发抓取任务。 - DNS 解析： 将
__address__标签中的主机名解析为 IP 地址。 - HTTP 请求： 向
http://<ip>:<port>/metrics发送 GET 请求，设置scrape_timeout超时。 - 响应读取： 读取 HTTP 响应体，逐行解析样本。
- 标签注入： 将配置中的
relabel_configs和metric_relabel_configs应用到样本。 - 样本暂存： 解析后的样本写入 Head Block（内存中的最新数据区域）。
- 健康上报： 更新
up指标（1=成功，0=失败）和scrape_duration_seconds。
2.3.2 抓取配置关键参数
| 参数 | 默认值 | 对误差预算的影响 |
|---|---|---|
scrape_interval |
15s | 间隔越大，数据粒度越粗，SLO 计算窗口内的样本数越少 |
scrape_timeout |
10s | 超过此时间未收到完整响应则放弃，产生数据空洞 |
honor_labels |
false | 若为 false，Server 会重写 Exporter 暴露的标签，可能导致台账标签丢失 |
sample_limit |
0（无限制） | 超过限制时丢弃多余样本，台账数据不完整 |
2.3.3 抓取失败重试与退避
Prometheus 对抓取失败不进行重试。一次超时或 HTTP 错误（如 500、503）直接导致该周期数据丢失，直到下一个 scrape_interval 触发。这种“无重试”设计是为了避免级联雪崩，但也意味着：
- 网络抖动超过
scrape_timeout就会产生数据空洞。 - 误差预算台账必须将“抓取失败次数 × scrape_interval”计入不可用时间。
2.4 链路故障排查要点
- 可达性面板：
up{job="..."}时间序列，标记所有 0 值的时间段。 - 延迟面板：
scrape_duration_seconds的 P99 与scrape_timeout对比。 - 样本量面板：
scrape_samples_scraped的突变检测，突然下降可能表示 Exporter 内部故障。 - 错误日志面板： Prometheus Server 的
target_scrape_pool_exceeded_sample_limit_total等指标。
通过本节对采集链路全景的拆解，可以明确：误差预算台账的校准不能仅依赖 up 指标，必须结合 scrape_duration_seconds、scrape_samples_scraped 以及 Exporter 端点的响应质量进行综合判断。下一环节将深入 Exporter 内部实现，分析指标采集与转换过程中的精度损失点。