2. Prometheus 架构回顾：主节点与辅助节点的角色划分，数据流与查询路径分析

在构建辅助节点滚动升级的容量规划基线之前，必须首先厘清 Prometheus 标准部署架构中主节点（Primary）与辅助节点（Secondary）的职责边界、数据流转路径以及查询请求的完整生命周期。本节将基于最常见的 Prometheus + Thanos 或 Prometheus + VictoriaMetrics 联邦架构进行拆解，为后续的容量模型提供结构基础。

2.1 主节点与辅助节点的角色划分

在大型监控部署中，主节点与辅助节点并非简单的“主从复制”关系，而是通过 联邦（Federation） 或 远程写入（Remote Write） 实现分层职责分离。下表从数据采集、存储、查询、生命周期四个维度对比两者的核心差异：

2.2 数据流路径分析

数据从目标 exporter 产生到最终被辅助节点存储，经历三个关键阶段。下图展示了主节点与辅助节点之间的数据流转关系：

数据流的关键特征可归纳为以下步骤：

1. 采集阶段： 主节点以固定间隔（通常 15s）抓取 Exporter 暴露的 /metrics 端点，写入本地 TSDB。
2. 联邦阶段： 辅助节点通过 /federate?match[]={__name__=~"node_.*"} 等匹配规则，从主节点拉取预聚合指标。此阶段是容量规划的核心——联邦拉取的频率、匹配规则数量、指标基数直接影响辅助节点的网络与 CPU 开销。
3. 存储与降采样： 辅助节点将拉取到的指标写入本地 TSDB，并执行降采样规则（如 5m 分辨率保留 30d，1h 分辨率保留 90d），减少存储成本。

2.3 查询路径分析

查询路径根据时间范围和查询来源呈现不同的路由策略。下图展示了两种典型查询路径：

查询路径的容量规划要点：

• 实时查询（< 6h）： 直接命中主节点本地 TSDB，查询延迟通常 < 100ms。滚动升级主节点时，需将实时查询临时切换至辅助节点，但辅助节点可能缺少最新 1~2 个拉取周期的数据，导致仪表盘出现短暂空白。
• 历史查询（> 6h）： 路由至辅助节点，查询降采样数据。辅助节点滚动升级期间，若采用 --query.vertical-sharding 或 Thanos Query 前端，单节点离线会导致查询超时或结果不完整。
• 混合查询： 部分仪表盘同时请求实时与历史数据（如“同比”对比），此时查询层需要合并主节点与辅助节点的结果，对网络带宽和内存有额外消耗。

2.4 数据流与查询路径的容量影响因子

基于上述架构分析，下表汇总了与辅助节点滚动升级直接相关的容量影响因子，这些因子将作为后续章节构建基线模型的输入参数：