2. Prometheus 基础回顾：架构组件、数据模型与拉/推模式
在深入资源模型数据传输优化之前，必须重新校准 Prometheus 的核心基础。本章从架构组件、数据模型（Metric / Label / Sample）以及 Pull 与 Push 模式对比三个维度，建立后续优化讨论的共识。
2.1 核心架构组件
Prometheus 采用模块化设计，各组件职责清晰。下图展示了标准部署下的组件关系与数据流向：
关键组件职责速览：
- Prometheus Server：核心大脑，负责指标拉取（Retrieval）、时间序列存储（TSDB）、查询处理（PromQL）和告警规则评估。
- Exporter：将非原生支持 Prometheus 的应用（如 MySQL、Nginx、Linux 主机）的指标转换为 /metrics 端点。
- Pushgateway：允许短生命周期任务主动推送指标，解决批处理作业无法被 Pull 的问题。
- Alertmanager：处理告警去重、分组、静默和路由通知（邮件、PagerDuty、Slack 等）。
- Grafana：通过 Prometheus HTTP API 查询数据，构建可视化仪表盘。
2.2 数据模型：Metric / Label / Sample
Prometheus 的数据模型是理解一切优化的起点。所有存储、查询、压缩策略都围绕这个三元组展开。
| 概念 | 定义 | 示例 | 优化关注点 |
|---|---|---|---|
| Metric（指标名） | 标识被测量内容的名称，遵循 [a-zA-Z_:][a-zA-Z0-9_:]* 格式。 |
http_requests_total |
命名规范影响查询效率；过长的指标名增加存储开销。 |
| Label（标签） | 键值对，用于维度区分。每个时间序列由指标名 + 唯一标签集合标识。 | {method="GET", handler="/api", status="200"} |
标签基数（Cardinality）是性能瓶颈的核心来源。 |
| Sample（样本） | 时间戳 + 浮点数值的二元组，构成时间序列的一个数据点。 | 1620000000 1024.5 |
采样间隔、数据精度、压缩率直接影响磁盘和网络开销。 |
优化启示： 在资源模型传输优化中，标签基数是首要控制变量。一个高基数标签（如
user_id、request_id）可能使单个指标膨胀为数百万时间序列，导致 Pull 请求体巨大、TSDB 写入放大、查询超时。
2.3 Pull 与 Push 模式对比
Prometheus 默认采用 Pull 模式，但 Push 模式通过 Pushgateway 作为补充。理解两者的本质差异，是设计数据传输策略的前提。
常见误区： 不要将 Pushgateway 当作高可用或负载均衡方案。Pushgateway 是故障转移的薄弱环节——如果网关宕机，所有推送数据丢失；如果网关重启，旧指标残留可能导致错误告警。在资源模型传输优化中，应优先考虑 Pull 模式下的服务发现和分片策略，而非依赖 Push 模式。
2.4 模式选择决策矩阵
在实际架构中，选择 Pull 还是 Push 取决于工作负载特征。以下矩阵帮助快速决策：
| 场景 | 推荐模式 | 理由 |
|---|---|---|
| 长期运行的服务（Web、数据库、中间件） | Pull | 服务发现天然匹配，健康检查与指标采集合一。 |
| 批处理作业、CronJob、CI/CD 流水线 | Push | 任务结束后进程退出，无法被 Pull；Pushgateway 暂存指标。 |
| 网络隔离环境（目标无法被 Server 直接访问） | Push | 目标主动穿越防火墙推送指标到网关。 |
| 高基数、大规模集群（>10 万时间序列） | Pull + 分片 | Pull 模式便于水平扩展（Hash 分片、Federation），Push 模式容易导致网关过载。 |
| IoT / 边缘设备（间歇性连接） | Push | 设备离线时无法被 Pull，上线后主动推送缓存数据。 |
数据传输优化核心结论：
- Pull 模式在可控性、可观测性、扩展性上优于 Push 模式，是 Prometheus 的推荐范式。
- Push 模式是必要补充，但引入额外的传输延迟和单点风险，在优化中应限制其使用范围。
- 无论哪种模式，减少每次传输的样本数量（通过降低采样频率、聚合预计算、过滤无用标签）是通用的优化方向。