1. 课程导论：Prometheus 辅助节点滚动升级的背景与挑战
1.1 为什么需要滚动升级？
在大型 Prometheus 部署中，辅助节点（Sidecar / Agent / 远端存储写入节点）承担着指标采集、预聚合、数据转发等关键职责。当我们需要升级 Prometheus 版本、调整采集配置、更新 relabel 规则或替换底层存储时，滚动升级（Rolling Upgrade） 是保证服务连续性的首选策略。
滚动升级的核心目标：
- 零数据丢失：升级过程中不丢失已采集的指标数据。
- 零查询中断：Grafana 等消费端始终可查询到最新指标。
- 逐步替换：每次只升级一个或少数节点，避免全量故障。
关键认知：滚动升级不是简单的“重启 Pod”，而是需要精确控制流量、数据缓冲、写入窗口和副本状态的系统工程。
1.2 辅助节点滚动升级的典型挑战
实际运维中，辅助节点滚动升级常面临以下痛点：
| 挑战类别 | 具体问题 | 影响 |
|---|---|---|
| 数据一致性 | 升级期间节点下线，WAL 未完全 flush，导致小窗口数据丢失 | 指标断点，影响长期趋势计算 |
| 写入压力转移 | 节点下线后，上游采集器将流量转发给剩余节点，造成瞬时过载 | OOM / 请求超时 / 背压崩溃 |
| 查询路由 | Thanos / VictoriaMetrics 等查询层未及时感知节点状态变化 | 查询结果不完整或重复 |
| 版本兼容性 | 新旧版本 Prometheus 之间 WAL 格式、remote write 协议存在差异 | 写入失败或数据格式错误 |
| 回滚复杂度 | 升级失败后需要快速回退，但数据状态已部分变更 | 恢复时间长，影响 SLA |
常见误区：很多团队只关注“升级动作本身”，而忽略了升级前容量评估和升级中流量模型变化，导致升级窗口内出现级联故障。
1.3 容量规划基线的定义
容量规划基线（Capacity Planning Baseline） 是指在滚动升级前，对辅助节点集群的 稳态资源消耗 和 峰值负载能力 进行量化的基准线。它包含以下核心维度：
- CPU 使用率：正常采集 + 预聚合 + remote write 的 CPU 开销。
- 内存占用：WAL 缓存、内存中时间序列块、查询缓存。
- 磁盘 I/O：WAL 写入速率、TSDB block 压缩频率。
- 网络吞吐：接收指标速率（samples/s）与发送速率。
- 连接数：与上游采集器、下游存储之间的 gRPC/HTTP 连接。
基线的作用：
- 确定安全升级窗口：当集群负载低于基线 70% 时，可安全执行升级。
- 评估冗余容量：确保剩余节点能承接下线节点的流量。
- 设置告警阈值：升级期间若资源超过基线 120%，立即暂停或回滚。
1.4 容量规划基线的重要性
没有基线，滚动升级就是“盲人摸象”。以下是基线缺失的典型后果：
| 场景 | 无基线行为 | 有基线行为 |
|---|---|---|
| 节点下线 1 台 | 剩余节点 CPU 飙升 200%，触发 OOM | 提前确认剩余节点有 40% 冗余，平稳承接 |
| 升级后写入延迟 | 无法判断是版本问题还是负载问题 | 对比基线，延迟增量在预期范围内 |
| 回滚决策 | 凭感觉决定是否回滚，容易误判 | 资源超过基线阈值，自动触发回滚 |
最佳实践：容量规划基线应持续更新，每次升级后重新校准，形成“基线-升级-验证-新基线”的闭环。
1.5 滚动升级与容量规划的关系图
下图展示了辅助节点滚动升级过程中，容量规划基线如何贯穿始终：
1.6 课程目标与学习路径
本课程将帮助你构建一套可落地、可量化的容量规划基线体系，覆盖以下核心能力：
- 基线采集：使用 Prometheus 自身指标 + 自定义 exporter 采集辅助节点资源画像。
- 基线建模：基于历史数据建立 CPU/内存/网络/磁盘的稳态模型与峰值模型。
- 升级模拟：通过“节点下线模拟”验证基线冗余容量是否充足。
- 自动化执行：将基线阈值嵌入 CI/CD 管道，实现升级前自动检查。
- 回滚策略：基于基线偏差自动触发回滚，减少人工决策延迟。
课程产出：一套完整的 Prometheus 辅助节点滚动升级容量规划基线模板 + Prometheus 告警规则 + 自动化脚本框架，可直接用于生产环境。