为什么 VictoriaMetrics 正在替换 Prometheus？一次大规模可观测性迁移实录

请点击上方蓝字TonyBai订阅公众号！

大家好，我是Tony Bai。

在云原生可观测性的领域，Prometheus 无疑是王者。凭借其简洁的模型、强大的 PromQL 和活跃的社区，Prometheus 几乎定义了现代监控的行业标准。许多顶尖技术公司，包括 PingCAP，都将其作为核心产品的监控与告警解决方案。

然而，Prometheus 的架构缺陷使其在大规模监控中显得力不从心。我们经常看到像 Pinterest 这样的大型企业面临的真实挑战。当一个 TiDB 集群规模达到 700+ 节点，每秒处理 700K+ QPS 时，曾经可靠的“王者”开始露出疲态。用于故障诊断的核心工具 TiDB Clinic 在回放和分析这些大规模集群的指标时，Prometheus 开始频繁崩溃。

这迫使整个行业直面一个残酷的现实：在极限规模下，Prometheus 不再是最佳选择。最近，PingCAP 官方发布的一篇博文 详细记录了他们如何应对这一挑战，并最终选择用 VictoriaMetrics 完成“换心手术”的全过程。

压垮 Prometheus 的“五宗罪”

为了支持 Pinterest 这样的大客户，pingcap工程团队为 Prometheus 分配了“怪兽级”的硬件资源：一台拥有 96 核心 CPU 和 768GB RAM 的 i4i.24xlarge 实例。许多人曾天真地以为，只要资源给够，一切问题都能解决。

但事实并非如此。在高基数、高吞吐量的指标冲击下，Prometheus 暴露出了几个致命的、与资源无关的瓶颈：

• Out of Memory (OOM) 崩溃 在执行大型、复杂的查询时，尤其是时间跨度较长时，Prometheus 的内存消耗会急剧飙升，最终被系统 OOM Killer 无情终结。

• 漫长的恢复时间 OOM 之后，Prometheus 需要通过重放 WAL (Write-Ahead Log) 来恢复数据。对于海量数据，这个过程动辄需要 40 分钟以上，有时甚至会因为各种原因彻底失败。

• “死亡循环” 最令人绝望的是，WAL 重放过程本身就是一个高资源消耗的操作，它很可能再次触发 OOM。文章中提到，工程团队遇到过 Prometheus 在崩溃和重启的“死亡循环”中挣扎，迟