2. Prometheus 架构总览：核心组件、数据流与通信拓扑
Prometheus 采用 拉取（Pull） 为主的监控数据采集模型，辅以 推送（Push） 机制处理短生命周期任务。理解其核心组件及通信拓扑是进行故障排查的基础。本章将拆解 Prometheus Server、Alertmanager、Pushgateway 和 Exporter 四大组件，并梳理它们之间的数据流关系。
2.1 核心组件一览
| 组件 | 角色 | 关键特性 | 通信方向 |
|---|---|---|---|
| Prometheus Server | 监控核心 | 数据采集、存储、查询、告警规则评估 | 主动 Pull / 接收 Push |
| Alertmanager | 告警处理 | 告警去重、分组、静默、路由、通知 | 接收 Server 推送 |
| Pushgateway | 推送中转 | 接收短期任务指标，供 Server 拉取 | 接收 Push / 被 Pull |
| Exporter | 数据采集代理 | 将第三方系统指标转换为 Prometheus 格式 | 被 Pull |
架构要点： Prometheus Server 是唯一主动发起 HTTP 请求的组件（除 Pushgateway 场景外）。Exporter 和 Pushgateway 只被动等待拉取，Alertmanager 只接收推送。这种单向依赖简化了故障排查路径。
2.2 数据流与通信拓扑
下图展示了 Prometheus 生态中完整的指标数据流与组件间通信关系。箭头方向代表数据或告警的流动方向。
2.3 组件职责详解
2.3.1 Prometheus Server
- 数据采集：根据配置的
scrape_config，定期向目标 Exporter 或 Pushgateway 的/metrics端点发起 HTTP GET 请求。 - 时序存储：将拉取到的指标数据以自定义格式写入本地磁盘（TSDB），支持数据压缩与保留策略。
- 告警规则评估：周期性计算 PromQL 表达式，当条件满足时生成告警并推送至 Alertmanager。
- 查询接口：提供 PromQL 查询 API，供 Grafana 等可视化工具或命令行使用。
2.3.2 Alertmanager
- 告警去重：对相同告警进行合并，避免重复通知。
- 分组：按标签将告警归类，减少通知风暴。
- 静默与抑制：支持基于标签的静默规则，以及依赖告警的抑制逻辑。
- 路由与通知：根据配置的路由树，将告警发送至邮件、Slack、PagerDuty 等渠道。
2.3.3 Pushgateway
- 适用场景：批处理任务、短生命周期容器、无法被直接拉取的临时作业。
- 工作方式：任务结束时将指标推送到 Pushgateway，Prometheus Server 再定期从 Pushgateway 拉取。
- 注意事项：Pushgateway 是单点，需监控其可用性；指标过期需手动清理或设置
push_timeout_seconds。
2.3.4 Exporter
- 职责：将第三方系统（操作系统、数据库、中间件）的内部状态转换为 Prometheus 可识别的指标格式。
- 常见类型：Node Exporter（主机）、Blackbox Exporter（网络探测）、MySQL Exporter、JMX Exporter 等。
- 部署模式：通常与被监控对象同主机部署，或作为 Sidecar 容器运行。
2.4 通信拓扑关键点
| 通信对 | 协议 | 方向 | 故障排查要点 |
|---|---|---|---|
| Server → Exporter | HTTP / HTTPS | Pull | 网络可达性、端口开放、Exporter 进程存活、/metrics 端点响应 |
| Server → Pushgateway | HTTP / HTTPS | Pull | Pushgateway 服务状态、指标过期时间、数据完整性 |
| Server → Alertmanager | HTTP / gRPC | Push | Alertmanager 集群状态、告警队列积压、网络延迟 |
| 任务 → Pushgateway | HTTP | Push | 任务脚本正确性、Pushgateway 认证、指标命名冲突 |
| Alertmanager → 通知渠道 | SMTP / Webhook / Slack API | Push | 通知服务配置、、速率限制 |
常见陷阱： 如果 Prometheus Server 无法拉取 Exporter 数据，请优先检查
scrape_config 中的 targets 地址是否正确、Exporter 端口是否被防火墙拦截、以及 /metrics 端点是否返回 200 状态码。不要忽略 DNS 解析和网络超时设置。
2.5 数据流示例：一次完整的监控循环
- 采集：Prometheus Server 每 15 秒（默认
scrape_interval）向 Node Exporter 的http://node-exporter:9100/metrics发起 GET 请求。 - 存储：Server 解析返回的文本格式指标，写入本地 TSDB，并打上
job="node"、instance="node-exporter:9100"等标签。 - 评估：Server 执行告警规则
node_cpu_seconds_total > 0.9，触发告警。 - 推送：Server 将告警通过 HTTP 发送至 Alertmanager 的
/api/v1/alerts端点。 - 通知：Alertmanager 对告警进行分组、去重后，通过配置的邮件路由发送通知。
理解这个循环有助于快速定位故障环节：是采集失败、存储异常、规则未触发，还是告警通知未送达。