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 | 真·云原生横向扩展 TSDB | 超大型、SaaS、百万实例级 |
| M3 | Uber 打造的高性能监控引擎 | 高写入量、极致性能场景 |
你别被术语吓到，本质只是风格不同：
- 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 执行的时候，系统已经提前聚好了，速度快得飞起。
六、实际业务怎么选？一张表给你拍板
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 中型企业，Prom 规模几十台 | Thanos | 简单好用，几乎无迁移成本 |
| 大型企业，多租户、百万指标规模 | Cortex | 真正云原生扩展能力强 |
| 超高写入场景（金融/出行/广告） | M3 | 写入量大、延迟要求高 |
| 快速上线低成本方案 | Thanos | 低门槛 |
| 云原生平台/容器平台 | Cortex | 最灵活易扩展 |
| 单地域但数据量大 | Thanos 或 M3 | 看需求：功能 vs 性能 |
我一般建议：
- 先上 Thanos，易用性最高。
- 如果 Prom 集群已经 100+、指标量亿级，就考虑 Cortex。
- 如果写入量炸裂，就上 M3。
七、我的实战感受：别迷信单一方案，混搭往往更香
有一段时间我们做集群监控，非常典型的情况：
- Kubernetes + Prometheus Operator
- 多集群 Prometheus 抓指标
- Thanos 做全局聚合和长期存储
- 一部分高写入指标走 M3 做实时监控
你没看错：
监控系统不是非黑即白，不同特点的指标应该用最适合的存储。
例如：
- Pod 指标 → Thanos（易查、结构化）
- 网关 QPS、业务流量 → M3（大量高频）
- SaaS 多租户指标 → Cortex
这是很多大厂真正的落地方式。
八、总结：大规模 Prometheus 架构不是选谁，而是选适合你业务的扩展方式
如果你问我一句话怎么总结：
Thanos 是 Prometheus 的“外挂增强版”，Cortex 是 Prometheus 的“云原生集群版”，M3 是 Prometheus 的“性能爆炸版”。
想上大规模监控，关键不是工具本身，而是：
- 吞吐量到底多大
- 查询模式有没有全局需求
- 是否多租户
- 有几个机房
- 是否需要长期存储
- 团队有没有能力维护复杂系统
