3. Prometheus 采集架构：Pull模型、Push模型、采集作业生命周期

Prometheus 的采集架构是其性能基准测试与压测设计的核心基础。理解 Pull 模型、Push 模型 以及 采集作业（Scrape Job）生命周期，是后续制定压测指标、配置负载模型、分析瓶颈的前提。本章从架构原理出发，逐步拆解这三个关键概念。

3.1 Pull 模型：主动拉取架构

Prometheus 默认采用 Pull（拉取）模型。在这种架构中，Prometheus Server 作为主动方，定期向配置好的目标（Target）发起 HTTP 请求，获取指标数据。这种设计将采集控制权集中在 Server 端，便于统一调度与故障管理。

Pull 模型工作流程

1. 服务发现 / 静态配置： Prometheus 通过服务发现（Consul、Kubernetes）或静态配置文件（scrape_configs）获取目标列表。
2. HTTP GET 请求： 每个采集周期，Prometheus 向目标的 /metrics 端点发送 HTTP GET 请求。
3. 响应解析： 接收并解析返回的文本格式指标数据（Prometheus Exposition Format）。
4. 数据存储： 解析后的样本数据经过标签处理、时间戳对齐后写入本地存储（TSDB）。

Pull 模型优缺点对比

3.2 Push 模型：被动接收架构

虽然 Prometheus 原生是 Pull 模型，但在某些场景（如批处理任务、防火墙隔离的网络、IoT 设备）下，Target 无法被 Server 直接访问。此时需要 Push 模型 作为补充。Prometheus 通过 Pushgateway 组件实现 Push 能力。

Push 模型工作流程

• 客户端推送： 任务进程在结束时，将指标数据通过 HTTP POST 推送到 Pushgateway。
• 中间缓存： Pushgateway 作为指标缓存层，持久保留最后一次推送的数据。
• Server 拉取： Prometheus Server 仍然使用 Pull 模型，从 Pushgateway 的 /metrics 端点拉取聚合后的指标。

Pull vs Push 模型决策矩阵

3.3 采集作业生命周期

一个完整的 Scrape Job（采集作业） 从配置加载到数据落盘，经历多个阶段。理解每个阶段的耗时与资源消耗，是压测中定位瓶颈的关键。

生命周期阶段分解

1. 配置加载与目标发现： Prometheus 定期重新加载 scrape_configs，通过服务发现或文件 SD 更新目标列表。此阶段涉及网络请求（如 Consul API）或文件 I/O。
2. 目标实例化： 为每个目标创建 ScrapePool 和 ScrapeLoop，分配采集周期、超时、标签等参数。
3. HTTP 请求阶段：
   • DNS 解析（如果目标使用主机名）
   • TCP 连接建立（三次握手）
   • TLS 握手（如果启用 HTTPS）
   • 发送 HTTP GET 请求
   • 等待响应（Server 处理时间 + 网络延迟）
   • 读取响应体（指标数据流）
4. 数据解析与标签处理：
   • 解析 Prometheus Exposition Format 或 Protobuf
   • 应用 relabel_configs（标签重写、丢弃、保留）
   • 执行 metric_relabel_configs（指标级标签操作）
5. 样本存储： 将解析后的样本追加到 TSDB 的 Head Block，触发预写日志（WAL）写入。

采集作业生命周期流程图

3.4 采集性能关键参数

在压测中，以下参数直接影响采集作业的性能表现，需要在测试方案中明确配置：