2. Prometheus 架构回顾：采集器角色、Pull vs Push 模型与采集作业平台定位
在深入扩缩容与资源规划之前，必须重新梳理 Prometheus 采集体系的核心架构。本章聚焦三个关键问题：Exporter 在架构中扮演什么角色？ Pull 与 Push 模型各自的适用场景与代价？ 采集作业平台（如 Categraf / Telegraf）如何改变传统采集拓扑？
2.1 采集器（Exporter）的角色与职责
Exporter 是 Prometheus 生态中负责指标暴露的代理进程。它不负责存储、告警或查询，只做一件事：将目标系统的内部状态转换为 Prometheus 可抓取的 Metrics 格式（通常是 /metrics HTTP 端点）。
| 角色维度 | 说明 | 典型示例 |
|---|---|---|
| 数据源适配 | 从系统 API、日志、DB、硬件寄存器采集原始数据 | node_exporter 读取 /proc、/sys |
| 指标转换 | 将非标准数据映射为 Prometheus 四种指标类型（Counter、Gauge、Histogram、Summary） | redis_exporter 将 INFO 命令输出转为 Metrics |
| 标签注入 | 附加静态或动态标签（instance、job、自定义维度） | blackbox_exporter 注入 target 标签 |
| 健康暴露 | 通过 HTTP 端点提供 /metrics 和 /health | 所有官方 Exporter 默认实现 |
关键认知： Exporter 是“无状态翻译层”。它的资源消耗（CPU、内存、FD）直接与采集目标的规模、指标基数、采集频率成正比。扩缩容 Exporter 本质上是在“采集并发度”与“目标系统压力”之间做权衡。
2.2 Pull vs Push 模型：架构选择与代价
Prometheus 原生采用 Pull 模型：Server 主动连接 Exporter 拉取数据。但实际生产环境中，Push 模型（通过 Pushgateway 或采集作业平台）同样广泛存在。两种模型在采集拓扑、资源规划、故障隔离方面有本质差异。
| 对比维度 | Pull 模型 | Push 模型 |
|---|---|---|
| 控制方向 | Server 控制采集节奏 | Exporter/Agent 控制上报节奏 |
| 服务发现 | 依赖 SD 机制（Consul、K8s、文件） | Agent 已知目标地址，直接上报 |
| 故障隔离 | Exporter 宕机仅影响该目标 | Pushgateway 单点故障影响全局 |
| 扩缩容复杂度 | 需调整 Server 抓取配置或 SD | 需调整 Agent 路由或负载均衡 |
| 典型场景 | 长期运行的服务、基础设施 | 批处理任务、短生命周期作业 |
常见误区： 不要将 Pushgateway 当作“高可用采集网关”使用。Pushgateway 是批处理指标暂存器，不是采集代理。大量使用 Pushgateway 会导致指标过期、标签爆炸、单点瓶颈。对于大规模采集，应优先使用 Pull 模型或采集作业平台。
2.3 采集作业平台的定位：Categraf / Telegraf
传统 Exporter 模式存在一个显著问题：每个目标系统需要独立部署一个 Exporter 进程。当监控规模达到数千节点、数百种中间件时，Exporter 进程数量爆炸，管理成本急剧上升。采集作业平台（如 Categraf、Telegraf）正是为解决此问题而生。
2.3.1 采集作业平台的核心能力
- 多采集器聚合：单个 Agent 进程内同时运行多个 input 插件，替代多个独立 Exporter。
- 统一生命周期管理：Agent 的部署、升级、配置下发、健康检查全部集中化。
- 本地数据缓冲与重试：在网络抖动或 Server 不可用时，Agent 在本地缓存指标数据，避免数据丢失。
- 协议转换与聚合：支持将数据推送到多个后端（Prometheus、InfluxDB、Kafka），或进行预聚合降低基数。
| 对比维度 | 传统 Exporter 模式 | 采集作业平台（Categraf / Telegraf） |
|---|---|---|
| 进程数量 | N 个目标 = N 个 Exporter 进程 | 1 个 Agent 进程承载 M 个采集插件 |
| 配置管理 | 每个 Exporter 独立配置文件 | 中心化配置下发（etcd / 配置文件） |
| 资源开销 | 每个 Exporter 独立占用端口、FD、内存 | 共享进程资源，开销更低 |
| 扩缩容粒度 | 按 Exporter 实例扩缩 | 按 Agent 实例扩缩，内部插件动态启停 |
| 典型部署 | 每个主机部署 3~8 个 Exporter | 每个主机部署 1 个 Agent |
生产建议： 在 500 节点以上的集群中，强烈推荐使用采集作业平台替代散装 Exporter。Categraf 在“采集器热加载”、“插件隔离”、“指标过滤”方面比 Telegraf 更适配 Prometheus 生态。Telegraf 的优势在于插件生态更丰富，适合混合后端场景。
2.4 采集作业平台在 Prometheus 架构中的位置
采集作业平台并不是替代 Prometheus Server，而是重构了采集层。在典型部署中，Categraf / Telegraf 部署在目标主机上，通过 Pull 或 Push 方式将指标发送到 Prometheus Server 或第三方网关。其定位可以概括为：
- 采集层抽象：屏蔽底层 Exporter 的多样性，对外提供统一的指标端点或上报接口。
- 资源整合器：将多个采集任务的资源开销合并到一个进程内，降低整体资源占用。
- 弹性边界：在 Agent 层面实现采集能力的水平扩缩，Server 层无需感知采集拓扑变化。
架构演进趋势： 从“每个目标一个 Exporter”到“每个主机一个 Agent”，再到“每个集群一个 Agent 池”。采集作业平台是 Prometheus 生态从“单体采集”走向“采集网格”的关键基础设施。在后续章节中，我们将基于 Categraf 的插件模型，详细讲解如何设计采集器的扩缩容策略与资源配额。