2. Prometheus 监控体系基础：架构、数据模型与采集模式

在《Prom与IDP制品签名链路集成性能调优方案》中，Prometheus 是整个监控与告警体系的核心数据底座。理解其架构、数据模型以及 Pull/Push 模式的适用边界，是后续对签名链路进行延迟分析、资源规划与性能调优的前提。本节将系统梳理 Prometheus 的基础知识，并重点对比 Pull 模式与 Pushgateway 的适用场景。

2.1 Prometheus 整体架构

Prometheus 采用 拉取（Pull） 为主的监控架构，核心组件包括 Prometheus Server、Exporter、Pushgateway、Alertmanager 以及数据可视化层（Grafana）。其工作流如下：

• Prometheus Server：负责定时从 Exporter 或 Pushgateway 拉取指标数据，存储于本地 TSDB（时间序列数据库），并提供 PromQL 查询接口。
• Exporter：部署在被监控目标上，将业务或系统指标转换为 Prometheus 可识别的格式，暴露 HTTP 端点供 Server 拉取。
• Pushgateway：用于接收短生命周期任务（如批处理作业）推送的指标，作为临时指标缓存，再由 Server 拉取。
• Alertmanager：处理 Prometheus Server 发出的告警，进行去重、分组、静默并发送通知。
• Grafana：通过 PromQL 查询 Prometheus 数据，进行可视化仪表盘展示。

2.2 数据模型：时间序列与标签

Prometheus 所有采集的数据均以 时间序列（Time Series） 形式存储。一个时间序列由 指标名称（Metric Name） 和一组 标签（Labels） 唯一标识。

• 指标名称：描述被监控指标的含义，例如 sign_duration_seconds、sign_requests_total。
• 标签：键值对形式，用于对指标进行维度划分，例如 service="idp-signer"、key_type="rsa"、status="success"。
• 样本（Sample）：时间序列中某个时间点的具体数值，由时间戳和浮点数值组成。

Prometheus 支持四种核心指标类型：

2.3 Pull 模式：核心采集机制

Pull 模式是 Prometheus 的默认采集方式。Prometheus Server 根据配置的 scrape_config，定期（默认 15s）向目标 Exporter 的 HTTP 端点发起 GET 请求，拉取指标数据。

Pull 模式的优势：

• 控制权在 Server：Server 决定拉取频率、超时、重试策略，便于集中管理。
• 健康检查天然集成：如果目标 Exporter 无响应，Server 立即感知，可触发告警。
• 避免指标风暴：Server 按自身节奏拉取，不会因客户端突发推送导致过载。
• 安全性：目标只需暴露 HTTP 端点，无需反向连接 Server，减少攻击面。

Pull 模式的局限：

• 无法直接采集 短生命周期任务（如 CI/CD 构建容器、批处理作业），因为任务结束后 Exporter 也随之销毁。
• 网络环境复杂时（如目标位于 NAT 或防火墙后），Server 可能无法直接访问 Exporter。

2.4 Pushgateway：补充短任务场景

Pushgateway 是 Prometheus 生态中用于解决 短生命周期任务 监控的组件。其工作流程为：

1. 任务在启动或结束时，主动将指标通过 HTTP POST 推送到 Pushgateway。
2. Pushgateway 将指标缓存在内存中，并暴露 HTTP 端点。
3. Prometheus Server 定期从 Pushgateway 拉取这些缓存指标。

Pushgateway 的适用场景：

Pushgateway 的注意事项：

• 指标不会自动过期：Pushgateway 会一直保留已推送的指标，直到被新的推送覆盖或手动删除。这可能导致监控图上出现“僵尸”数据点。
• 单点故障风险：Pushgateway 本身需要高可用部署，否则会影响所有依赖它的任务。
• 不适合高频率推送：频繁推送（如每秒一次）会给 Pushgateway 和 Prometheus Server 带来额外压力，建议仅在任务开始/结束时推送。

2.5 采集模式选择建议

在 IDP 制品签名链路中，建议遵循以下原则进行采集模式选型：