3.2 自建 Prometheus 与替代方案：VictoriaMetrics、Mimir 的...

3.2 自建 Prometheus 与替代方案：VictoriaMetrics、Mimir 的硬核选型

我在几个团队都遇到过同样的焦虑：series 数量涨到几十万，团队就开始讨论"是不是该上 VictoriaMetrics"。每次我都会先泼一盆冷水——很多情况是基数没控好，先治理基数，单机 Prometheus 的上限比你想象的高。这一节给一个明确的观点：过早上重型架构，会让复杂度反噬可观测性本身。我们用硬核对比讲清楚，什么时候单机 Prometheus 够用，什么时候必须换，以及换什么。

先判断：你真的需要换吗

考虑替代方案前，先看你的 Prometheus 有没有真的触顶。我给一组经验阈值，是基于多个项目的实战总结。

series 100 万以下、抓取间隔 15 秒以上，单机 Prometheus 完全够用，别折腾。这个量级下，如果觉得慢，大概率是基数没控好（见 3.1 节）或者查询写得低效，先治这两个，单机能再扛很久。

series 100 万到 500 万，或者抓取间隔短于 10 秒，开始要优化了——降基数、做分片、加内存——但未必需要换引擎。这个阶段的很多"性能问题"，通过治理就能解决，换引擎是最后手段。

series 超过 500 万，或者有多团队多租户的需求，认真考虑长期方案（VictoriaMetrics、Mimir、Cortex）。到这个量级，单机的扩展性确实到头了。

一个常见的误区是把"单实例顶不住"误判为"必须换引擎"。实际上很多情况是基数没控好——先治理基数，往往单机 Prometheus 就能再扛很久。我曾经帮一个团队把 series 从 300 万治理到 80 万（移除了一堆历史遗留的高基数指标），原本计划换 VictoriaMetrics 的项目直接取消，单机 Prometheus 又稳定跑了两年。先治基数，再谈换引擎，这是正确的顺序。

三大方案硬核对比

把自建 Prometheus、VictoriaMetrics、Grafana Mimir 三个主流方案做个硬核对比。

存储压缩方面，Prometheus 一般，VictoriaMetrics 极好（它就是为高基数和压缩率优化的），Mimir 也不错。查询语言方面，三者都支持 promql，VictoriaMetrics 用 MetricsQL（promql 的超集，有一些扩展），兼容性很好。水平扩展方面，Prometheus 难（需要分片或 federation 这种变通方案），VictoriaMetrics 有原生的集群版，Mimir 是原生分布式的。多租户方面，Prometheus 无，VictoriaMetrics 集群版支持，Mimir 是原生强多租户（这是它的核心卖点）。运维复杂度方面，Prometheus 低（单二进制），VictoriaMetrics 中，Mimir 高（它是微服务架构，十几个组件）。长期存储方面，Prometheus 需要配 Thanos 或 Cortex，VictoriaMetrics 单机版就能存历史，Mimir 原生支持。

什么时候选 VictoriaMetrics

VictoriaMetrics 是当下推理监控场景最实用的升级路径。推荐时机是 series 超过 200 万、单机 Prometheus 内存吃紧；需要存长期历史（数月到年级），又不想搭 Thanos 那套复杂栈；看重存储压缩和查询性能。

VM 的核心优势有几个。单二进制部署（单机版）极简，运维成本低。压缩率比 Prometheus 高数倍（同样的数据占用更少的磁盘和内存）。promql 协议兼容，可以直接替换 Prometheus，Grafana 数据源几乎零改动。集群版可以水平扩展，应对规模增长。

坑点也要说清楚。MetricsQL 与 promql 有细微差异，极少数高级查询的行为不同，迁移时要做测试。高基数虽然优化了，但仍然不是无上限——治理基数依然是基本功。社区生态不如 Prometheus 原生那么丰富，某些 exporter 和集成可能需要适配。

我的建议是：series 破百万、且确认基数已治理到位后，VM 是最稳妥的升级选择。它的迁移成本最低（协议兼容），收益最直接（压缩和性能）。

什么时候选 Mimir

Grafana Mimir 适合大型组织、多团队、强多租户的场景：多个独立团队共享一套监控，需要严格的租户隔离与配额；已经深度使用 Grafana Cloud 生态（Loki/Tempo/Mimir 一体）；团队有专职可观测性 SRE，能驾驭其微服务架构的运维复杂度。

Mimir 的核心卖点是原生强多租户和水平扩展，这是它比 VM 强的地方。但它的代价是运维复杂度极高——微服务架构意味着 distributor、ingester、querier、store-gateway 等十几个组件，每个都要维护、监控、扩缩容。这套复杂度对大型组织是值得的（多租户隔离的刚需），但对中小团队是灾难——监控本身变成了新的故障源和运维负担。

我强烈不建议中小团队用 Mimir。见过有创业公司为了"技术先进性"上了 Mimir，结果两个 SRE 有一半时间在维护 Mimir 本身，业务监控反而没精力做。监控是手段不是目的，别让手段反噬目的。

过渡期的折中方案：Prometheus + 远程写入

如果还没到非换不可，又想为未来铺路，最稳的过渡方案是：本地 Prometheus 加远程写入（remote_write）到 VM 或 Mimir 做长期存储。短期查询走本地 Prometheus（快），长期历史和高基数走 VM（省），迁移成本最低，且可随时切换后端。这个架构既保留了 Prometheus 的简单（本地短期数据），又获得了 VM 的压缩和扩展性（长期存储），是渐进式迁移的最佳路径。

很多团队最终都会演进到这个混合架构，而不是一刀切地替换。它给了你灵活性——业务变化时可以调整本地和远程的边界，而不必推倒重来。

这一节与第三章的收尾

关于选型的核心结论：别过早换引擎，先治基数，单机 Prometheus 的上限比想象的高。series 破百万后再认真考虑 VictoriaMetrics（实用首选）或 Mimir（大型多租户）。过渡期用"Prometheus + remote_write"最稳，是渐进式迁移的最佳路径。

至此第三章完成。下一章我们进入实战——把指标变成能看懂、能告警、能行动的看板与告警体系。