66,196 颗星、13 年老项目：Prometheus 在 2026 年的真实位置——以及它已经不该被孤立地看

打开任何一个中大型后端团队的监控大盘，最先映入眼帘的那条曲线，大概率来自 Prometheus。这个 2012 年 11 月由 SoundCloud 工程师起步的项目，如今拿着 66,196 颗 GitHub Star、10,851 个 Fork 和 1,158 个 Watch，在 2026 年的云原生观测栈里依然是最底层的那个坐标原点。它现在的处境有点微妙：不再是最”性感”的项目，却是最多生产系统绕不开的那块地基。

66,196 颗星这个数字，现在该怎么读

Prometheus 进入 CNCF 已经是很多年前的事，Apache-2.0 许可证、Go 语言实现，仓库 github.com/prometheus/prometheus 目前挂着 905 个 open issue——这个数字放在 6 万星的项目上其实不算健康也不太糟糕，说明维护者(核心团队 + 社区)在做严格筛拣，不是来者不拒。

更值得看的是发版节奏。最近三个版本是 v3.15.0-rc.1（2026-09-21）、v3.15.0-rc.0（2026-09-09）和 v3.13.3（2026-09-07）。注意 3.13.3 是被当作 LTS 维护线在走的——它打了一批安全补丁，包括把 github.com/klauspost/compress 升到 v1.18.7（GO-2026-5841）和 golang.org/x/crypto 升到 v0.55.0（GO-2026-6303）。官方明确提出 LTS 概念，本身就是一个信号：这个项目已经不追求”快”，而是把”稳”当作第一优先。对生产环境来说，这反而是好事。

Prometheus 到底在解决什么问题，边界在哪

它的核心设计二十年没变过：用拉取（pull）模型定期抓取指标，把数据存成本地时序库，用 PromQL 查询，用 Alertmanager 触发告警。真正区分它与其他监控系统的是三件事——多维数据模型（metric 名 + 一组 label）、PromQL 这个表达力极强的查询语言、以及单节点自治、不依赖分布式存储。

这个”单节点自治”是它最大的优点，也是它最大的天花板。

搞清楚边界很重要：

• 适合：Kubernetes 原生监控、微服务架构、单集群或中小规模（大致在 100 万活跃 series 以内）、短期留存（15–30 天）就够用的场景。它的 exporter 生态几乎覆盖了所有能想象到的东西。
• 不适合：需要数月到数年长期留存、活跃 series 轻松破百万、多租户隔离、或者想用它做计费/交易级精确统计的场景。Prometheus 的拉取模型会丢样本，它从来不是为”每一笔都算准”设计的，而是为”运维健康度”设计的。

有技术对比文章直接把话说透：在高基数（high cardinality）下，像 user_id、session_id、request_id 这类无界标签就是灾难。社区的经验值是单个 metric 的标签组合一旦失控，存储会以每月每指标几 GB 的速度膨胀。有团队因为给一个 http_request_count 加上 user_id 标签，两小时内 metric 数从 12 万飙到 420 万。

真实使用门槛：比你想的高

很多人以为 Prometheus 是”装个 Docker 就能用”，那是玩具级认知。真实门槛体现在：

1. 基数治理是基本功，不是可选项。上线前要用 promtool 做基数审计，在 scrape 层用 relabel 把无界标签丢掉或 hashmod 分桶，还要设 sample_limit 兜底。不做这件事，你的 Prometheus 迟早会 OOM。
2. PromQL 的坑很深。rate() 窗口至少要 2 个样本，经验法则是 range duration ≥ 4 倍 scrape interval；irate() 不适合告警因为它只看最后两个点；increase() 会向区间边界外推，整数计数器会算出 59.8 这种小数；经典直方图的 bucket 部署后不能改。这些都是踩过才知道的。
3. 长期存储要另请外援。想存一年，本地 SSD 方案不现实——有案例算过 13 个月本地留存要 14TB SSD，月成本约 2,800 美元。标准做法是配 Thanos（对象存储 + 全局查询 + 降采样）或加一层远端写入。

2026 年的真实战局：它不再是唯一解

这是本文最想说的部分。2026 年做监控选型，Prometheus 已经不能孤立地看，它活在一个明确的竞争格局里：

• VictoriaMetrics：Prometheus 兼容的 drop-in 替代，用 LSM 树。公开基准里同样数据量下内存占用比 Prometheus 低数倍，社区里有 5–10 倍省 RAM 的说法。单二进制部署、MetricsQL 是 PromQL 超集，Grafana 数据源几乎零改动。适合”series 破百万 + 想省资源”的团队。坑点是 MetricsQL 与 PromQL 有细微差异（尤其 native histogram 边界），迁移要测。
• Grafana Mimir：方向相反，是”更大的 Prometheus”。水平分片、对象存储、原生强多租户。v3.0（2025 年 11 月）引入了用 Kafka 做异步缓冲的解耦架构，以及流式查询引擎（MQE），把查询峰值内存降低了最多 92%。适合有平台团队、需要 SaaS 级规模的组织，运维复杂度高，生产部署要十几个组件。
• Thanos：不替换 Prometheus，而是给它加装长期存储和全局查询。迁移风险最小，代价是多出 Sidecar、Store Gateway、Compactor、Querier 几个组件。

一张流传较广的对比表给了很直白的定位：Prometheus 是”单集群”答案，Thanos 是”已有 Prometheus 舰队”答案，Mimir 是”企业多租户”答案，VictoriaMetrics 是”成本效率”答案。

判断与下一步建议

如果是新项目、规模不大，先用官方 Prometheus：文档最全、生态最广、社区答案最多，学习成本和踩坑成本都最低。别一上来就上 Mimir。

如果你已经踩到墙，按这个顺序排查：

1. 先确认不是基数没治。很多”Prometheus 不行了”最后发现是 label 没管好。
2. 次之确认不是留存策略错配。30 天运维指标没必要存一年。
3. 真到了百万 series 以上、内存吃紧，再考虑 VictoriaMetrics（迁移成本最低）。
4. 需要多租户或 SaaS 级规模，才轮到 Mimir。

最后一条给所有用它的人：把你的 Prometheus 版本停在 LTS 线上（当前 3.13.x 是维护线，可以关注官方 LTS 页面 prometheus.io/docs/introduction/release-cycle），生产环境别追 rc 版。3.15 的两个 rc 都是给下一个大版本做铺垫的，值得看，但不值得在核心监控链路上赌。

装它、用它、理解它的边界——这才是 2026 年对待 Prometheus 的正确姿势。