2. Prometheus 架构回顾：Pull 模型、Pushgateway、Service Discovery、数据存储与查询

在深入控制面弹性伸缩的故障排查之前，必须重新校准对 Prometheus 核心架构的理解。生产环境中 90% 的采集异常都源于对 Pull 模型、Pushgateway 边界、服务发现机制以及存储查询原理的认知偏差。本节将逐一拆解这四个关键组件，并建立故障排查的架构视角。

2.1 Pull 模型：核心采集范式

Prometheus 采用 主动拉取（Pull） 模式，由 Server 端根据配置或服务发现结果，定期向目标暴露的 HTTP 端点（通常是 /metrics）发起 HTTP GET 请求。这与传统的推模式（如 StatsD、InfluxDB）有本质区别。

2.2 Pushgateway：短生命周期任务的桥梁

Pushgateway 是 Pull 模型的补充组件，允许批处理或短生命周期任务在退出前将指标推送到 Pushgateway，再由 Prometheus 从 Pushgateway 拉取。但 Pushgateway 并非万能网关，使用不当会引入严重故障。

• 正确用法： 定时任务（CronJob）、CI/CD 流水线、一次性数据迁移作业。
• 错误用法： 替代 Node Exporter 采集系统指标、作为长期运行的指标代理、用于高基数指标。
• 核心风险： Pushgateway 不会自动清理过期指标，若任务未正确调用 pushadd 或 delete API，会导致指标残留，造成数据混乱和存储膨胀。

2.3 Service Discovery：动态目标的自动发现

在 Kubernetes 环境中，Pod 和 Service 的 IP 会频繁变化。服务发现（SD）机制让 Prometheus 能够动态感知目标变化，无需手动修改配置文件。Kubernetes SD 是最常用的发现方式。

2.4 数据存储与查询：TSDB 与 PromQL

Prometheus 内置了高性能的时序数据库（TSDB），所有采集到的样本数据按时间戳和标签索引存储。查询语言 PromQL 是故障排查的核心工具。

2.4.1 TSDB 存储结构

• Block 存储： 数据按 2 小时时间窗口切分为 Block，每个 Block 包含独立的索引、元数据、样本数据。
• WAL（Write-Ahead Log）： 在数据写入 Block 前先写入 WAL，保证崩溃恢复时数据不丢失。
• 压缩与保留： 后台定期压缩 Block，删除超过保留期的旧数据。

2.4.2 PromQL 查询基础

故障排查中最常用的 PromQL 模式：

# 查询当前时刻的指标值
up{job="kube-apiserver"}

# 查询过去 5 分钟的平均值
avg_over_time(up{job="kube-apiserver"}[5m])

# 计算速率（适用于 Counter 类型）
rate(http_requests_total{job="kube-apiserver"}[1m])

# 标签聚合
sum by (instance) (rate(http_requests_total{job="kube-apiserver"}[1m]))

2.5 架构总结与故障排查映射

将上述组件串联起来，形成完整的采集链路。故障排查时，可以按以下层次逐级定位：

1. 服务发现层： 目标是否被正确发现？标签是否匹配？
2. 网络层： Prometheus 能否访问目标 IP:Port？是否存在网络策略或 mTLS 阻断？
3. 采集层： 目标是否返回有效的 /metrics 端点？HTTP 状态码是否为 200？
4. 存储层： 数据是否成功写入 TSDB？是否存在 WAL 损坏或磁盘空间不足？
5. 查询层： PromQL 语法是否正确？标签选择器是否精确？