拓冰网站定制 
Prometheus 3.0 升级3 步不停机迁移指南【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus上个月我们把生产监控从 2.45 升到 Prometheus 3.0第一次直接停了 20 分钟没备份 TSDB可以理解为 Prometheus 自己的本地时序数据库新进程启动后旧进程读不了新索引数据直接凉凉。第二次换了个姿势——新旧实例并行跑 48 小时数据追上后再切流量切换窗口只有 3 秒。下面把这条路径整理出来。Prometheus 3.0 升级路径怎么选判断依据就一条v3 的 TSDB 数据只有 v2.55 及以上的版本能读回滚时最低只能退到 v2.55。据此对照你的当前版本你的版本推荐路径判断条件v2.40 及以下先升 v2.55跑一周再升 v3跨度大直接升容易在 TSDB 格式转换上翻车v2.41 ~ v2.54先升 v2.55 观察再升 v3官方迁移文档明确建议把 v2.55 当保险垫见 docs/migration.mdv2.55直接升 v3回滚路径清晰可退回 2.55已有 3.x 混部不用动只需对齐配置参数动手备 → 验 → 切新旧实例共用同一批 scrape target各自落到独立的存储卷旧实例在切换后保留 24~48 小时做热备。 备好三样东西当前配置文件、完整的 TSDB 目录、新版二进制缺一不可。备份只做一次cp -r /var/lib/prometheus /var/lib/prometheus_backup_$(date %F)校验点用新版二进制跑promtool check config退出码为 0 才算配置过关再用du -sh对比源目录和备份目录大小一致。✅ 验证数据没丢新实例从空存储启动靠持续抓取追数据所以别只看进程活着要看数据进度curl -s http://127.0.0.1:9091/api/v1/query?querycount({__name__~.})校验点同一条查询在旧实例上执行两边序列数差值小且随时间收敛v3 的/api/v1/status/tsdb/blocks接口实现见 web/api/v1/api.go能看到新 block 在持续生成。 把流量切过去确认新实例/-/ready返回 200 后把负载均衡 selector 指过去。如果中途只改过配置用生命周期接口热加载前提是启动参数带了--web.enable-lifecyclecurl -X POST http://127.0.0.1:9091/-/reload校验点切换后 Grafana 上核心大盘没有断点旧实例保持运行至少 24 小时再下线。Prometheus 3.0 升级后你多解锁了什么原生直方图。开一个开关新采集的 series 就带动态分桶分位数查询不再依赖手写的le桶global: scrape_native_histograms: true查询照旧histogram_quantile(0.95, sum(rate(http_req_duration_seconds[5m])))但底层分桶数量比固定桶少一个量级。OTLP 原生写入。启动参数加--web.enable-otlp-receiverOpenTelemetry Collector 直接往 4318 端口推指标省掉中间适配层otlp: translation_strategy: NoUTF8EscapingWithSuffixesUTF-8 指标名。含特殊字符甚至中文的指标名现在能被正常接收依赖旧校验逻辑的任务在对应 job 上加一行metric_name_validation_scheme: legacy即可锁回老行为。le值统一。v2 里同一个直方图走文本协议进来是le1、走 protobuf 进来是le1.0两条 series 悄悄分裂v3 统一归一化成浮点跨协议的大盘和告警不再缺半边。避坑速查表现象原因一条修复启动报unknown field scrape_classic_histogramsv3 把参数改名为always_scrape_classic_histogramssed -i s/scrape_classic_histograms/always_scrape_classic_histograms/g prometheus.yml大批 target 抓取失败报 Content-Type 错误v3 不再默默按文本协议猜校验变严给对应 job 加fallback_scrape_protocol字段le1的告警、查询突然不匹配v3 把le/quantile归一化成浮点规则改成le1.0或用正则le~1(\\.0)?带.的正则匹配出更多目标v3 里.会匹配换行符把.替换成[^\n]告警推送失败v3 不再支持 Alertmanager v1 API配置改api_version: v2Alertmanager 升到 0.16.0关键项v2v3remote_write的enable_http2默认开默认关要开需显式声明正则.不匹配换行匹配换行le/quantile值随抓取协议变化统一浮点UTF-8 指标名拒绝默认支持TSDB 向下兼容—只有 v2.55 能读今晚就拿 v3 的二进制给你的现行配置跑一遍promtool check config输出全绿的话就可以照着备 → 验 → 切三步排期了。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Prometheus 3.0 升级：3 步不停机迁移指南
Prometheus 3.0 升级3 步不停机迁移指南【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus上个月我们把生产监控从 2.45 升到 Prometheus 3.0第一次直接停了 20 分钟没备份 TSDB可以理解为 Prometheus 自己的本地时序数据库新进程启动后旧进程读不了新索引数据直接凉凉。第二次换了个姿势——新旧实例并行跑 48 小时数据追上后再切流量切换窗口只有 3 秒。下面把这条路径整理出来。Prometheus 3.0 升级路径怎么选判断依据就一条v3 的 TSDB 数据只有 v2.55 及以上的版本能读回滚时最低只能退到 v2.55。据此对照你的当前版本你的版本推荐路径判断条件v2.40 及以下先升 v2.55跑一周再升 v3跨度大直接升容易在 TSDB 格式转换上翻车v2.41 ~ v2.54先升 v2.55 观察再升 v3官方迁移文档明确建议把 v2.55 当保险垫见 docs/migration.mdv2.55直接升 v3回滚路径清晰可退回 2.55已有 3.x 混部不用动只需对齐配置参数动手备 → 验 → 切新旧实例共用同一批 scrape target各自落到独立的存储卷旧实例在切换后保留 24~48 小时做热备。 备好三样东西当前配置文件、完整的 TSDB 目录、新版二进制缺一不可。备份只做一次cp -r /var/lib/prometheus /var/lib/prometheus_backup_$(date %F)校验点用新版二进制跑promtool check config退出码为 0 才算配置过关再用du -sh对比源目录和备份目录大小一致。✅ 验证数据没丢新实例从空存储启动靠持续抓取追数据所以别只看进程活着要看数据进度curl -s http://127.0.0.1:9091/api/v1/query?querycount({__name__~.})校验点同一条查询在旧实例上执行两边序列数差值小且随时间收敛v3 的/api/v1/status/tsdb/blocks接口实现见 web/api/v1/api.go能看到新 block 在持续生成。 把流量切过去确认新实例/-/ready返回 200 后把负载均衡 selector 指过去。如果中途只改过配置用生命周期接口热加载前提是启动参数带了--web.enable-lifecyclecurl -X POST http://127.0.0.1:9091/-/reload校验点切换后 Grafana 上核心大盘没有断点旧实例保持运行至少 24 小时再下线。Prometheus 3.0 升级后你多解锁了什么原生直方图。开一个开关新采集的 series 就带动态分桶分位数查询不再依赖手写的le桶global: scrape_native_histograms: true查询照旧histogram_quantile(0.95, sum(rate(http_req_duration_seconds[5m])))但底层分桶数量比固定桶少一个量级。OTLP 原生写入。启动参数加--web.enable-otlp-receiverOpenTelemetry Collector 直接往 4318 端口推指标省掉中间适配层otlp: translation_strategy: NoUTF8EscapingWithSuffixesUTF-8 指标名。含特殊字符甚至中文的指标名现在能被正常接收依赖旧校验逻辑的任务在对应 job 上加一行metric_name_validation_scheme: legacy即可锁回老行为。le值统一。v2 里同一个直方图走文本协议进来是le1、走 protobuf 进来是le1.0两条 series 悄悄分裂v3 统一归一化成浮点跨协议的大盘和告警不再缺半边。避坑速查表现象原因一条修复启动报unknown field scrape_classic_histogramsv3 把参数改名为always_scrape_classic_histogramssed -i s/scrape_classic_histograms/always_scrape_classic_histograms/g prometheus.yml大批 target 抓取失败报 Content-Type 错误v3 不再默默按文本协议猜校验变严给对应 job 加fallback_scrape_protocol字段le1的告警、查询突然不匹配v3 把le/quantile归一化成浮点规则改成le1.0或用正则le~1(\\.0)?带.的正则匹配出更多目标v3 里.会匹配换行符把.替换成[^\n]告警推送失败v3 不再支持 Alertmanager v1 API配置改api_version: v2Alertmanager 升到 0.16.0关键项v2v3remote_write的enable_http2默认开默认关要开需显式声明正则.不匹配换行匹配换行le/quantile值随抓取协议变化统一浮点UTF-8 指标名拒绝默认支持TSDB 向下兼容—只有 v2.55 能读今晚就拿 v3 的二进制给你的现行配置跑一遍promtool check config输出全绿的话就可以照着备 → 验 → 切三步排期了。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考