prometheus 升级需分阶段推进，小版本可直接升级，大版本须经 v2.55 lts 中转；tsdb 格式不兼容需备份与 remote_read 迁移；配置参数须人工校验并用 promtool 检查；生产环境推荐双实例零停机切换；生态组件须同步协调升级。
Prometheus 升级不是简单换镜像，关键在于版本跨度、数据兼容性与组件协同。小版本可直接升级，大版本（如 v2.x → v3.0 或跨 major 版本）必须分阶段推进，否则极易导致数据不可读、告警失效或服务中断。
明确版本升级路径，避开格式陷阱
TSDB 存储格式变更是一道硬门槛：
- v2.0 起启用全新 tsdb，与 v1.x 数据完全不兼容；若从 v1.x 升级，需先停写旧实例，用
remote_read接入旧数据，再部署新实例 - v2.40 以下版本不能直升 v3.0；官方推荐路径是 v2.x → v2.55（LTS）→ v3.x，v2.55 是唯一支持向 v3.0 平滑过渡的中间版本
- v3.0 使用改进索引格式，虽向下兼容 v2.55+ 的数据，但升级前仍需执行完整备份：
cp -r /var/lib/prometheus /var/lib/prometheus_backup_$(date +%F)
配置与参数迁移必须人工校验
新版常修改或移除旧参数，自动升级会失败：
-
scrape_classic_histograms已重命名为always_scrape_classic_histograms -
remote_write.enable_http2默认值由true改为false，若依赖 HTTP/2 写入，需显式设为true - 务必用
promtool check config prometheus.yml验证配置语法，尤其检查alert_rules、scrape_configs和remote_write区块
零停机升级靠双实例并行切换
生产环境禁止单点升级。推荐 Kubernetes 下采用双实例架构：
- 新实例使用独立 PVC（如
storageClassName: ssd）、独立 Service 端口（如9091），避免端口冲突 - 旧实例保持只读 +
remote_read，新实例启动后先验证指标采集与查询结果一致 - 通过 Ingress 或 Service Mesh 将流量逐步切至新实例，观察 1–2 个完整采集周期后再下线旧实例
生态组件需同步协调升级
Prometheus 很少单独存在，Operator、Exporter、Alertmanager 必须匹配：
- Helm 用户：升级
kube-prometheus-stack前，先helm repo update，再按UPGRADE.md检查 CRD 是否需提前更新 - NGINX Exporter 从 v0.7.0 升到 v0.8.0，镜像地址变为
nginx/nginx-prometheus-exporter:0.8.0，且默认以非 root 用户运行，需调整 PodSecurityPolicy - go-grpc-prometheus 中，
prometheus.NewServerMetrics()已废弃，统一替换为NewServerMetrics(counterOpts)并确保拦截器注册生效
不复杂但容易忽略
