监控告警发布于 2026/7/21更新于 2026/7/218分钟阅读顶有教育科技

Prometheus 3 迁移清单：运维要关注哪些兼容性变化

Prometheus 3 带来若干不兼容变化，本文从运维角度整理 feature flags、scrape target、GOMEMLIMIT、GOMAXPROCS、规则和告警的迁移检查。

Prometheus 是云原生监控中最常见的组件之一。Prometheus 3 已经发布，官方迁移指南明确指出，相比 2.x，它包含一些向后不兼容变化。

对运维团队来说，Prometheus 升级的风险不只是服务能不能启动，更关键的是：采集目标是否变化、告警规则是否仍然准确、远程写入是否正常、资源限制是否符合预期。

为什么 Prometheus 升级要谨慎

Prometheus 往往处在告警链路的核心位置：

exporter -> Prometheus -> Alertmanager -> 通知渠道

如果 Prometheus 升级后采集异常，可能出现两类问题：

真故障没有告警。
假告警大量触发。

所以监控系统升级本身也要被监控。

关注点一：部分 feature flags 已成为默认行为

Prometheus 3 移除了一些 feature flags，并把它们纳入默认行为。例如：

promql-at-modifier
promql-negative-offset
new-service-discovery-manager
expand-external-labels
no-default-scrape-port
agent
remote-write-receiver
auto-gomemlimit
auto-gomaxprocs

如果旧启动参数里还带着这些 flags，Prometheus 3 会给出 warning。

升级前先检查：

ps aux | grep prometheus
cat /etc/systemd/system/prometheus.service

Kubernetes 环境检查：

kubectl get deploy,statefulset -A | grep prometheus
kubectl get pod -n monitoring -o yaml | grep enable-feature

关注点二：scrape target 端口表现变化

Prometheus 3 中，no-default-scrape-port 成为默认行为。这意味着 Prometheus 不再按 scheme 自动补默认端口到 target 标签中。

如果你的规则或 dashboard 依赖类似下面的标签值：

https://example.com/metrics:443
http://example.com/metrics:80

升级后可能变成不带端口的形式。

建议检查：

Grafana dashboard 是否按 instance 精确匹配。
PromQL 是否写死 :9100、:443。
告警分组是否依赖 instance。

关注点三：GOMEMLIMIT 和 GOMAXPROCS 自动适配

Prometheus 3 默认会根据 Linux 容器内存限制设置 GOMEMLIMIT，并根据 CPU quota 设置 GOMAXPROCS。

这对 Kubernetes 环境通常是好事，因为 Prometheus 更能感知容器资源限制。

但如果你过去通过环境变量手工设置过这些值，要重新评估：

kubectl describe pod prometheus-0 -n monitoring
kubectl top pod prometheus-0 -n monitoring

如果升级后查询变慢或内存回收频繁，要同时看资源限制、TSDB 大小和查询压力。

关注点四：remote write receiver 参数变化

旧的 remote-write-receiver feature flag 被替换为明确参数：

--web.enable-remote-write-receiver

如果你的 Prometheus 接收其他组件的 remote write，一定要验证写入端是否还能成功。

可以检查日志：

journalctl -u prometheus -f

Kubernetes 中：

kubectl logs -n monitoring prometheus-0 -f

迁移前的检查清单

备份配置文件。

cp prometheus.yml prometheus.yml.bak

导出当前规则。

find rules -type f -name "*.yml"

检查启动参数。

prometheus --version

用 promtool 检查配置。

promtool check config prometheus.yml
promtool check rules rules/*.yml

在测试环境跑一份相同配置。
升级后观察至少一个完整告警周期。

升级后的重点验证

up
scrape_duration_seconds
scrape_samples_scraped
prometheus_tsdb_head_series
prometheus_rule_group_last_duration_seconds

如果 up 大量变为 0，要先看 target 配置和网络。
如果规则执行变慢，要看 rule group 和查询表达式。
如果内存上涨，要看 series 数量和 label 维度。

总结

Prometheus 3 的迁移重点不是“命令能不能启动”，而是采集标签、规则、告警和资源限制是否仍符合预期。

学习监控运维时，Prometheus 升级是很好的实战场景。它会逼你理解指标、标签、规则、TSDB、资源限制和告警链路，而不是只会打开 Grafana 看图。