Thanos vs Cortex：谁才是 Prometheus 大规模长期存储的最优解？

在云原生监控领域，Prometheus 已成为事实上的标准。然而，原生的 Prometheus 在面对大规模、多集群以及长周期数据存储时，存在着明显的痛点：本地存储容量受限、缺乏全局视图、不支持高可用（HA）以及查询效率随数据量增加而剧烈下降。

为了解决这些问题，CNCF 社区涌现出了两个重量级项目：Thanos 和 Cortex。两者都旨在为 Prometheus 提供无限的存储空间和全局查询能力，但在架构设计哲学上却各走一端。

一、 Thanos：渐进式的 sidecar 扩展

Thanos 的设计哲学是“非侵入式”和“模块化”。它最常见的部署模式是通过 Sidecar 与现有的 Prometheus 实例并存。

1. 核心架构组件

• Sidecar: 与 Prometheus 运行在同一 Pod 中，负责读取本地 TSDB 数据并将其上传到对象存储（如 S3、OSS）。
• Querier: 实现 Prometheus API，负责下发查询请求给 Sidecar 或 Store Gateway，并进行数据去重和聚合。
• Store Gateway: 负责在对象存储中检索历史数据。
• Compactor: 负责对对象存储中的数据进行压缩和降采样（Downsampling）。
• Receiver: 允许 Prometheus 通过 remote_write 写入数据，适用于某些无法部署 Sidecar 的环境。

2. Thanos 的优势

• 易于上手：你可以无缝地在现有 Prometheus 上增加 Sidecar，不需要重构监控链路。
• 成本极低：核心依赖是廉价的对象存储，不需要维护复杂的分布式数据库。
• 查询去重：天然支持 HA 部署下的数据去重逻辑。

二、 Cortex：为多租户而生的微服务架构

如果说 Thanos 是 Prometheus 的“补丁和增强”，那么 Cortex 更像是一个“托管式的云监控服务”。它从诞生之初就将多租户（Multi-tenancy）和横向扩展作为核心目标。

1. 核心架构组件

Cortex 采用高度微服务化的架构：

• Distributor: 接收 remote_write 请求，并将数据分发给 Ingester。
• Ingester: 在内存中缓存最近的数据，并定期刷新到长期存储。
• Querier / Query Frontend: 负责查询切分、缓存和并行执行。
• Table Manager / Compactor: 处理底层存储索引和数据块。

2. Cortex 的优势

• 原生多租户：在数据摄入和查询路径上完全隔离不同租户，非常适合企业级内部监控平台或 SaaS 服务。
• 实时性强：由于采用 remote_write 模式，数据几乎实时推送到中央集群，不依赖于 Sidecar 的两小时块上传逻辑。
• 极致扩展性：每个组件都可以独立缩扩容，应对每秒千万量级的样本写入。

三、 深度维度对标：Thanos vs Cortex

四、 如何进行方案选型？

在实际生产中，没有绝对的“谁更好”，只有“谁更适合”。

1. 优先选择 Thanos 的场景：

• 已有成熟的 Prometheus 体系：不想破坏现有的 Pull 模型架构，只需增加长期存储和跨集群查询功能。
• 运维人力有限：Thanos 的 Sidecar 模式和无状态组件维护起来相对简单。
• 预算敏感：对对象存储的依赖度极高，整体资源开销更小。

2. 优先选择 Cortex 的场景：

• 严格的多租户需求：你需要向不同的业务部门或客户提供隔离的监控服务，并有计费或配额管理需求。
• 超大规模摄入量：监控指标规模达到亿级，需要通过高度分片的微服务来承载写入压力。
• 追求极速查询：Cortex 的 Query Frontend 缓存机制和查询并行度在处理海量数据聚合时表现更优。

五、 趋势：两者正在“合流”

有趣的是，Thanos 引入了 Receiver 组件开始支持 Push 模式，而 Cortex 近两年也全面转向了基于 Prometheus TSDB 的 Blocks Storage 模式（弃用了早期的 NoSQL 存储）。这意味着两者在底层数据格式上已经达成了一致。

对于大多数中型企业而言，Thanos 往往是性价比最高的“第一选择”；而对于希望构建统一监控平台的平台组，Cortex 提供的多租户治理能力则更具长远价值。

你的团队目前正在使用哪种方案？在实际运维中遇到了哪些坑？欢迎在评论区分享讨论。