1. Prometheus 架构总览：核心组件与数据流
Prometheus 是一个开源的系统监控与告警工具包，其核心设计理念是拉取（Pull）模型。理解其整体架构是进行性能调优与资源配额规划的前提。本章将逐一拆解 Prometheus Server、TSDB、Alertmanager、Pushgateway 四大核心组件，并通过数据流图展示指标从采集到告警的完整路径。
1.1 核心组件一览
| 组件 | 职责 | 关键特性 |
|---|---|---|
| Prometheus Server | 指标采集、存储、查询、告警规则评估 | Pull 模式抓取目标；内置时序数据库（TSDB）；支持 PromQL 查询；触发告警规则后推送至 Alertmanager |
| TSDB | 高效存储和压缩时序数据 | 自定义存储格式；支持 2 小时 block 合并与压缩；内存映射（mmap）加速查询；支持 WAL 与数据回放 |
| Alertmanager | 告警路由、去重、静默、通知 | 接收 Prometheus Server 推送的告警；分组抑制；支持邮件、PagerDuty、Slack 等接收器 |
| Pushgateway | 接收短生命周期任务的指标推送 | 允许批处理或无法被 Pull 的任务主动推送指标；作为指标的中转缓存 |
架构要点：Prometheus Server 是整个系统的中枢，TSDB 是存储基石，Alertmanager 负责告警生命周期管理，Pushgateway 是 Pull 模型的补充。性能调优的核心往往集中在 Server 的抓取能力与 TSDB 的 I/O 效率上。
1.2 数据流图：从指标采集到告警通知
下图展示了 Prometheus 生态中一条完整的指标数据流。箭头方向代表数据或告警的传递方向。
1.3 组件交互与数据流详解
- 指标采集阶段：Prometheus Server 根据配置的
scrape_config，定期向目标 Exporter 或应用暴露的 HTTP 端点发起 Pull 请求，获取指标数据。对于无法直接 Pull 的批处理任务，由任务主动向 Pushgateway 推送指标，Server 再统一从 Pushgateway 拉取。 - 存储阶段：Server 将拉取到的样本数据写入内嵌的 TSDB。TSDB 按 2 小时为一个 block 进行数据压缩与合并，并利用 WAL（Write-Ahead Log）保证数据可靠性。
- 查询与告警评估阶段：用户通过 PromQL 查询 TSDB 中的数据。Server 定期评估告警规则，当规则表达式持续满足阈值条件时，生成告警事件。
- 告警通知阶段：告警事件被推送至 Alertmanager。Alertmanager 根据路由配置对告警进行分组、抑制、静默，最终通过配置的接收器（如邮件、Webhook）发送通知。
性能关注点：在数据流中，Pull 抓取和TSDB 写入是 Prometheus Server 最消耗 CPU 和 I/O 的两个环节。当目标数量超过 1000 个或每秒样本数超过 50 万时，需要重点优化抓取间隔、样本大小以及 TSDB 的 block 压缩参数。
1.4 组件部署关系与资源边界
在生产环境中，各组件可以独立部署，也可以合并部署。下表列出了常见的部署模式及其资源隔离建议：
| 部署模式 | 组件组合 | 资源配额建议 |
|---|---|---|
| 单机 All-in-One | Server + TSDB + Alertmanager | 4C / 16GB RAM / 500GB SSD（小规模 < 500 目标） |
| 分离部署 | Server + TSDB（独立节点） Alertmanager（独立节点） |
Server: 8C / 32GB RAM Alertmanager: 2C / 4GB RAM |
| 高可用联邦 | 多个 Server + 联邦层 + 独立 Alertmanager 集群 | 按每 1000 目标分配 8C / 32GB RAM 基线 |
注意：Pushgateway 通常不与其他组件共享高负载节点，因为它可能成为短任务指标的单点瓶颈。建议为 Pushgateway 单独分配 1C / 2GB RAM 资源，并设置合理的指标过期时间（
--pushgateway.expiry-interval）。