2. 整体架构总览：Prometheus 生态组件全景图
Prometheus 并非一个单一的二进制程序，而是一个由多个独立组件构成的 采集与告警生态。理解每个组件的职责以及它们之间的数据流动关系，是设计高可用监控平台的基础。
2.1 核心组件与职责
下表列出了 Prometheus 生态中最关键的 5 类组件，它们共同构成了从数据采集到告警通知的完整链路。
| 组件 | 核心职责 | 部署形态 |
|---|---|---|
| Prometheus Server | 数据拉取、存储、查询（PromQL）、告警规则评估 | 中心化服务，通常为 1 个或多个实例组成 HA 对 |
| Exporter | 将非 Prometheus 格式的指标（如系统、中间件）转换为 Prometheus 可拉取的 HTTP /metrics 端点 | Sidecar 或独立进程，与被监控目标同机部署 |
| Pushgateway | 接收短期任务（批处理、CronJob）推送的指标，供 Server 拉取 | 独立中间层服务 |
| Alertmanager | 接收 Server 发出的告警，进行去重、分组、静默、路由，最终发送通知 | 独立服务，通常部署 3 节点保证高可用 |
| Client Library | 供应用开发者嵌入代码，直接暴露 /metrics 端点（如 Go、Java、Python SDK） | 内嵌于应用进程中 |
架构要点： Prometheus Server 是整个生态的“大脑”，Exporter 是“感官”，Alertmanager 是“声带”。Pushgateway 是专门为无法被拉取的短期任务设计的“临时缓冲区”。
2.2 数据流与拉取模型（Pull Model）
Prometheus 采用 主动拉取（Pull） 作为默认的数据采集模型，这与传统的推模型（Push）有本质区别。拉取模型的核心优势在于：Server 控制采集节奏，避免目标端突发流量导致数据丢失。
标准数据流路径如下：
- 指标暴露： Exporter 或应用通过 Client Library 在目标主机上暴露 HTTP 端点（默认
/metrics）。 - 服务发现： Prometheus Server 通过服务发现（Consul、Kubernetes、文件）获取目标列表。
- 定时拉取： Server 根据
scrape_interval（默认 15s）向目标发起 HTTP GET 请求。 - 数据存储： Server 解析返回的文本格式指标，存入本地 TSDB（时间序列数据库）。
- 规则评估： Server 定期评估告警规则和记录规则。
- 告警推送： 触发告警时，Server 将告警发送至 Alertmanager。
- 通知分发： Alertmanager 处理后通过 Email、PagerDuty、Webhook 等渠道通知运维人员。
拉取 vs 推送对比：
- 拉取优势： 更容易控制采集频率、避免目标端过载、天然支持健康检查（拉取失败即代表目标不可用）。
- 推送适用场景： 防火墙隔离、短期任务（CronJob）、无法暴露端口的遗留系统（此时使用 Pushgateway 作为中转）。
2.3 整体架构数据流图
下图展示了 Prometheus 生态组件之间的完整数据流向与交互关系。箭头方向代表数据或告警的流动方向。
2.4 组件交互时序与关键配置
为了更清晰地理解组件间的协作关系，下面以一次完整的指标采集与告警流程为例，展示各组件在时间轴上的交互。
2.5 关键配置示例
以下是一个典型的 Prometheus Server 配置文件片段，展示了如何定义拉取目标（Exporter）和告警规则文件路径。
# prometheus.yml
global:
scrape_interval: 15s # 全局拉取间隔
evaluation_interval: 15s # 告警规则评估间隔
# 拉取目标配置
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['192.168.1.10:9100', '192.168.1.11:9100']
- job_name: 'pushgateway'
honor_labels: true # 保留 Pushgateway 传递的标签
static_configs:
- targets: ['localhost:9091']
# 告警规则文件
rule_files:
- 'alerts/*.yml'
# 告警接收端
alerting:
alertmanagers:
- static_configs:
- targets: ['localhost:9093']
生产注意事项：
- 不要将 Pushgateway 用于长期运行的进程，它仅适用于短期任务。长期使用会导致指标过期堆积，增加 Server 拉取压力。
- Alertmanager 必须部署至少 2 个实例并配置集群模式，避免单点故障导致告警丢失。
- Exporter 的
/metrics端点应限制访问来源（如通过防火墙或反向代理），防止未授权拉取。