从改良到重塑：解构 Prometheus 监控架构的三种哲学与选型真相
回望过去几年在可观察性领域的摸爬滚打，尤其是围绕 Metrics 体系的建设，感觉就像是一场漫长的架构修行。从最开始守着单机 Prometheus 还要担心磁盘爆满，到后来引入 Thanos 试图做“无限存储”，再到如今用 Mimir 重构整个监控中枢，这些经历散落在记忆里，甚至有些细节已经开始模糊。
最近静下心来，把这些年踩过的坑、做过的技术决策重新梳理了一遍，忽然发现：这其实并不是一个单纯的技术迭代故事，而是一次次面对不同规模痛点时的哲学抉择。那些曾经以为是“升级版”的方案，实则是完全不同的物种。今天这篇，就当作是对这段遗忘经验的抢救性概括，聊聊我眼中的三种架构形态，以及为什么在特定规模下，Mimir 会成为那个“对”的选择。
模式一：原教旨主义 —— 单机 Prometheus
架构哲学
这是 Prometheus 最初的设计理念：简单、独立、去中心化。每个 Prometheus Server 独立负责采集（Pull）、存储（Local TSDB）和查询。
核心特征
- 计算存储耦合：采集与存储在同一进程内完成，部署极简。
- 数据自治：每个集群的数据就在本地，不依赖外部系统。
局限性
这并非一种可扩展的架构。随着数据量增长，本地磁盘成为瓶颈，且缺乏全局视角，多集群管理如同一个个数据孤岛。
模式二：改良主义 —— Thanos Sidecar 模式
为了解决单机版的痛点，Thanos 应运而生。它采取了一种**“非侵入式改良”**的哲学：尽量保留 Prometheus 的原有架构，通过外挂组件来增强能力。
架构本质：Pull-based 扩展
- Sidecar 机制：Thanos 以 Sidecar 形式部署在 Prometheus 旁，将本地生成的 TSDB 数据块上传至对象存储（S3/GCS），实现了长期存储。
- 联邦查询：Querier 组件充当网关，实时向各个 Prometheus Sidecar 和对象存储发起查询，聚合成全局视图。
优势与代价
- 优势：平滑迁移，无需改动现有的 Prometheus 配置，依然保留了本地数据的快速查询能力。
- 代价：运维复杂度高。组件繁多（Sidecar, Store, Compact 等），且查询实时数据依赖边缘集群的网络稳定性，查询路径长，长尾延迟难以避免。此外，Sidecar 模式下，Prometheus 本身的内存压力依然存在。
模式三：云原生重构 —— Mimir (Remote Write) 模式
与 Thanos 不同，Mimir（及其前身 Cortex）选择了**“推翻重构”**的路线，拥抱 Push-based 哲学。它不再试图增强 Prometheus，而是将 Prometheus 降级为单纯的采集代理（Agent）。
架构本质：中心化计算存储分离
- Remote Write 协议：这是 Mimir 架构的基石。Prometheus 通过
remote_write将所有数据实时推送至中心的 Mimir 集群。 - 全中心化处理：Mimir 接管了所有的存储、索引、查询计算和告警规则。边缘集群变得极度轻量，甚至可以使用更轻量的 Grafana Agent。
优势与代价
- 优势：极致的水平扩展性与多租户隔离。中心化架构使得 Mimir 可以对写入和查询进行精细的资源调度与优化。
- 代价：架构变重，对中心集群的稳定性要求极高。此外，Remote Write 传输的是实时流数据，相比 Thanos 上传压缩块，对跨地域网络带宽的消耗更高。
深度解密：为什么说 Mimir 是成本杀手？
虽然 Thanos 和 Mimir 都利用了廉价的对象存储，但 Mimir 在超大规模场景下（如数亿指标/秒）展现出了惊人的成本优势。这并非魔法，而是源于底层设计的差异。
1. 也是最关键的：I/O 操作的降维打击
云厂商对象存储账单的“刺客”往往不是存储容量，而是API 调用次数（PUT/GET 请求）。
- Thanos：Sidecar 每 2 小时上传一个 Block。虽然单体频率不高，但随着集群数量线性增长，总体请求量依然可观。
- Mimir：其 Ingester 组件拥有智能的内存缓冲机制，能够将海量的小微写入请求在内存中聚合成大块数据，再批量写入对象存储。这极大减少了 PUT 请求的数量，在大规模写入场景下，能节省巨额的 API 调用费用。此外，Mimir 的 Compactor 组件在后台默默合并 Block，进一步减少了 Object 数量，降低了后续查询的 GET 开销。
2. 用“算力”换“存储”的查询哲学
- Thanos：为了加速长周期查询（如查询一年的数据），Thanos 通常必须依赖降采样（Downsampling），即额外存储 5m、1h 精度的低分辨率数据副本。这不仅增加了计算开销，更直接导致存储成本成倍增加。
- Mimir：它引入了极为强悍的分片查询引擎（Split-and-Merge）。当查询一年数据时，Mimir 将其拆解为数十个子任务并行计算。这种架构让降采样不再是高性能查询的“必需品”。在大多数场景下，你完全可以只存储一份原始数据，就能获得亚秒级的查询响应，从而直接节省约 50% 的存储空间。
3. 存储格式的极致压缩
Mimir 对 TSDB 索引进行了深度优化，相比原生 Prometheus 的索引格式，Mimir 的索引文件更小，进一步降低了存储容量需求。
选型指南：不是升级，而是抉择
综上所述，从 Thanos 到 Mimir 并不是一个必然的升级过程，而是基于业务规模和运维哲学的抉择：
- 路径 A（稳健改良派）：如果你管理着中型规模集群，已有稳定的 Prometheus 设施，且不希望进行伤筋动骨的架构改造，或者边缘到中心的网络带宽昂贵，Thanos 依然是最佳选择。它是目前最流行的开源扩展方案。
- 路径 B（激进云原生派）：如果你面临超大规模监控挑战（如单一视图需承载数亿指标），需要构建支持硬隔离的多租户监控 PaaS 平台，或者希望极致优化对象存储成本，那么 Remote Write + Mimir 是当之无愧的终极方案。它代表了监控架构向中心化、服务化演进的未来方向。
总之，要能根据实际的业务痛点，去选择最适合自己的那把“手术刀”。