Prometheus 撑不住了？上 Thanos、Cortex、M3！一篇给你讲明白大规模监控的江湖

大家好，我是 Echo_Wish。今天咱聊一个运维人绕不过的现实问题：

业务疯狂长，指标像下雨一样砸进来，Prometheus 单机那点小身板，撑得住吗？

你别说，还真撑不住。

当指标量从几十万级往千万、亿级爬的时候，Prometheus 的痛点会一个接一个地冒出来：

• 存储爆炸
• 查询变慢
• 单点崩溃
• 多机房聚合困难
• 长期数据留存压力大

于是，“Prometheus 增强组件三巨头”横空出世：

Thanos、Cortex、M3 —— 三大大规模监控系统的天花板级架构。

今天咱不玩废话，直接告诉你：

• 它们能解决什么？
• 哪个更适合你？
• 架构到底啥样？
• 怎么落地？
• 为什么大厂都这么用？

用运维人的口吻总结一句话：

Prometheus 是家用电饭煲；Thanos/Cortex/M3 是工地 50 升大铁锅，炒啥都不怕爆。

一、为什么 Prometheus 在大规模场景下必挂？（痛点先亮出来）

1）存储有限

Prometheus 是本地 TSDB（Time Series Database），磁盘一满直接玩完。

2）横向扩展弱

多台 Prometheus 不共享数据，每个都是孤岛。

3）Cross-cluster 查询很难

跨机房、跨地域做聚合，非常费劲。

4）历史数据成本高

长期数据要么丢，要么手动压缩存 OSS/HDFS，过程痛苦。

5）PromQL 在大规模查询下变慢

业务稍一查全局，Prometheus 就先跪。

所以，大规模监控系统必须满足四个硬指标：

• 无限扩展
• 全局查询
• 多集群合并
• 长期低成本存储

而这，就是 Thanos、Cortex、M3 出场的理由。

二、三巨头快速对比：一句话总结风格

你别被术语吓到，本质只是风格不同：

• Thanos：最容易上手，最贴近原生 Prometheus。
• Cortex：最云原生，要依赖对象存储 + 微服务架构。
• M3：最性能怪兽。

三、Thanos：Prometheus 的“黄金外挂”

为什么最常用？
因为它几乎不用改 Prometheus，把多个 Prom 实例变成一个“超级大 Prom”。

Thanos 核心能力：

• 聚合多 Prometheus
• 通过 sidecar 同步数据到对象存储
• 全局查询
• 低成本长期存储
• 高可用

一句话：

原来的 Prom 你别动，我帮你变强。

核心架构长啥样？（简化版）

Prometheus -- Sidecar ----> Thanos Store ----> Object Storage (S3/OSS/COS)
                    \-----> Thanos Query <-----/

Thanos 配置示例（Sidecar）

args:
  - sidecar
  - --prometheus.url=http://127.0.0.1:9090
  - --tsdb.path=/prometheus
  - --objstore.config-file=/etc/thanos/objstore.yaml

Thanos 查询组件示例（Query）

args:
  - query
  - --store=thanos-storegateway:10901
  - --store=sidecar-prom01:10901
  - --store=sidecar-prom02:10901

就这点配置，你的 Prometheus 就从单机小弟升级成集群大佬。

四、Cortex：真正云原生 Prometheus 集群

Cortex 是 CNCF 项目，也是 Grafana 公司主推的方案。

它不像 Thanos 一样“加外挂”，而是：

自己做 TSDB，自己做多租户，自己做水平扩展。

更适合：

• 多租户 SaaS
• 云平台
• 多团队共享监控系统

Cortex 架构的核心关键词：

• 微服务组件（ingester、querier、distributor…）
• Ring 管理
• 对象存储
• 高可用
• 分片与副本

写入流程逻辑（伪代码示例）

func ingest(sample) {
    hash := hashFunc(sample.seriesID)
    ingester := ring.lookup(hash)
    ingester.append(sample)
}

这“hash 打散”的方式让 Cortex 可以无限横向扩展。

查询流程（简化）

func query(expr) {
   shards := distributor.split(expr)
   results := parallel(shards)
   return merge(results)
}

是不是云原生味道很足？

缺点也明显：

• 组件多
• 部署复杂
• 运维门槛高

但只要上规模，你会发现：

比 Thanos 更能扛。

五、M3：性能狂魔的选择（Uber 出品）

M3 是 Uber 为了承受海量监控数据自研的监控系统。

最大的优势就是两个字：

快。稳。

核心特性：

• M3DB：高性能分布式时序数据库
• M3Coordinator：查询路由
• M3Aggregator：预聚合提升性能
• 自带多机房、强一致、水平扩展

Uber 监控规模你想象不到：

• 亿级时序
• 每秒百万+写入

Prometheus 纯靠自己？根本活不下来。

M3 写入 pipeline 示例

m3coordinator:
  listenAddress: 0.0.0.0:7201
  ingestion:
    metrics:
      type: unaggregated
      downsample: true

它会自动做预聚合：

sum(rate(http_requests_total[5m]))

在 M3 中会成为：

http_requests_total__sum_5m

也就是说你 PromQL 执行的时候，系统已经提前聚好了，速度快得飞起。

六、实际业务怎么选？一张表给你拍板

我一般建议：

• 先上 Thanos，易用性最高。
• 如果 Prom 集群已经 100+、指标量亿级，就考虑 Cortex。
• 如果写入量炸裂，就上 M3。

七、我的实战感受：别迷信单一方案，混搭往往更香

有一段时间我们做集群监控，非常典型的情况：

• Kubernetes + Prometheus Operator
• 多集群 Prometheus 抓指标
• Thanos 做全局聚合和长期存储
• 一部分高写入指标走 M3 做实时监控

你没看错：

监控系统不是非黑即白，不同特点的指标应该用最适合的存储。

例如：

• Pod 指标 → Thanos（易查、结构化）
• 网关 QPS、业务流量 → M3（大量高频）
• SaaS 多租户指标 → Cortex

这是很多大厂真正的落地方式。

八、总结：大规模 Prometheus 架构不是选谁，而是选适合你业务的扩展方式

如果你问我一句话怎么总结：

Thanos 是 Prometheus 的“外挂增强版”，Cortex 是 Prometheus 的“云原生集群版”，M3 是 Prometheus 的“性能爆炸版”。

想上大规模监控，关键不是工具本身，而是：

• 吞吐量到底多大
• 查询模式有没有全局需求
• 是否多租户
• 有几个机房
• 是否需要长期存储
• 团队有没有能力维护复杂系统