（四）：scrape模块详解 - 数据采集的底层逻辑

约 2148 字大约 7 分钟

2026-03-28

导语

Prometheus最核心的工作之一就是“采集数据”，而scrape模块是负责该工作的核心模块。本文从源码角度拆解scrape模块的实现逻辑，详解其如何按配置拉取数据、处理数据并写入TSDB。

前置知识：Prometheus Server 架构与模块定位

在深入scrape模块前，先明确其在Prometheus源码中的位置。Prometheus Server采用清晰的模块化设计，各核心目录分工如下：

config：解析配置文件为内部实例
discovery：服务发现组件
promql：查询语句解析与执行
scrape：核心模块，负责从监控目标（Target）拉取时序数据
storage：存储层封装（对接TSDB等存储）
web：API接口与UI界面提供

图4-1 Prometheus Server 源码目录结构

scrape模块作为数据采集的核心入口，是连接监控目标与存储层的关键桥梁，整体结构如下：

图4-2 scrape模块整体结构

一、核心概念：Target

Target是采集的目标对象，每个Target对应一个采集端点（例如node_exporter的9100端口），scrape模块会持续维护Target的运行状态与采集周期。

在Prometheus中，Target结构体完整抽象了采集目标，可通过Web UI（http://localhost:9090/metrics）直观查看其状态：

图4-3 Target 状态展示界面

1.1 Target 核心字段

discoveredLabels：Relabel处理前的原始标签（包含服务发现生成的__meta_类标签）
labels：Relabel处理后的最终标签，会随时序数据持久化至存储层
params：HTTP采集请求的URL参数（如自定义查询参数）
health：目标健康状态（枚举值：未知/正常/异常）
metadata：指标元数据缓存（包含指标名称、类型、描述、单位）

1.2 Target 核心方法

URL()：拼接协议、地址、路径、参数，生成最终的采集请求地址
report()：实时更新采集状态（包括采集耗时、错误信息、健康度）
offset()：打散首次采集时间，避免大量Target并发采集引发的性能瓶颈

二、核心接口与实现

scrape模块通过接口分层设计实现采集逻辑解耦，四大核心组件各司其职，保证采集流程的扩展性与稳定性。

2.1 scraper 接口：单次采集执行者

定义单个Target的单次采集行为，是采集流程最底层的核心接口，仅负责单次数据拉取与状态上报：

type scraper interface {
    // 拉取目标数据并写入指定缓冲区，返回采集标识（如目标ID）及错误信息
    scrape(ctx context.Context, w io.Writer) (string, error)
    // 上报本次采集的耗时、错误等状态信息
    report(start time.Time, dur time.Duration, err error)
    // 计算采集偏移量，用于打散首次采集时间
    offset(interval time.Duration) time.Duration
}

targetScraper是该接口的唯一实现，核心逻辑：

通过HTTP客户端向Target端点发送采集请求
支持gzip压缩数据的自动解压
将原始监控数据写入指定的IO缓冲区

2.2 loop 接口：周期采集主循环

定义周期性采集逻辑，一个loop实例对应一个Target，实例创建后不可重启或复用：

type loop interface {
    // 启动周期性采集：interval为采集周期，timeout为单次采集超时时间，errc用于传递错误
    run(interval, timeout time.Duration, errc chan<- error)
    // 停止采集并释放相关资源
    stop()
}