Grafana Mimir 评测：Prometheus 长期存储的横向扩展方案，单体模式与 AGPL 许可的取舍

它解决什么问题：Prometheus 的长期存储与全局查询

Prometheus 自带本地存储，但单机容量有限，数据保留时间短，而且多个 Prometheus 实例之间的数据无法统一查询。Grafana Mimir 正是为此设计：它提供一个可横向扩展的长期存储层，接收来自多个 Prometheus 实例的指标，并支持跨实例的聚合查询。它的目标用户是那些运行多套 Prometheus、需要统一监控视图的团队，或是需要将指标数据保留数月甚至数年的企业。Mimir 的 README 强调其“全球视图”能力，即查询引擎并行化执行，以应对高基数查询。这解决了 Prometheus 单机模式下无法回答“所有集群的总请求量”这类问题的痛点。

核心机制：对象存储、多租户与复制

Mimir 的架构核心是将数据写入对象存储，而非本地磁盘。它支持 AWS S3、Google Cloud Storage、Azure Blob Storage、OpenStack Swift 以及任何 S3 兼容存储。这意味着存储成本低且持久性高，但代价是查询延迟取决于对象存储的响应速度。数据在写入时会进行复制，以保证机器故障时不丢失指标，这是高可用性的基础。多租户方面，Mimir 在逻辑上隔离不同团队的数据和查询，并通过限制和 QoS 控制来公平分配容量。这种设计让多个业务单元可以共享同一套集群，但需要仔细配置租户限额，否则一个租户的突发流量可能影响他人。

部署方式：单体模式与生产就绪的权衡

Mimir 最吸引人的一点是部署简单。README 明确指出，使用单体模式，只需一个二进制文件，无需额外依赖即可运行。这适合测试或小规模场景。但生产环境通常需要分布式部署，官方文档提供了架构概览和配置指南，包括如何运行生产环境。这意味着从单体到分布式有一个跳跃，不是自动完成的。如果你只是评估 Mimir，可以用单体模式快速启动；但若要承载真实流量，必须阅读架构文档，设计组件拓扑，比如 distributor、ingester、querier 等角色。官方还提供了仪表盘、告警和 runbook，这些是运维的辅助工具，但前提是你愿意信任 Grafana 的运维实践。

获取与启动：命令与配置的关键点

根据仓库信息，Mimir 的二进制可以从 GitHub Releases 获取，例如 mimir-3.2.0 版本。启动单体模式，通常运行 `./mimir -config.file=/path/to/config.yaml`，配置文件中需要指定对象存储后端，比如 `storage: backend: s3`，并提供相应的访问密钥。具体命令和配置键在官方文档中有详细说明，但仓库 README 没有列出完整的示例。如果你要迁移，官方提供了从 Thanos 或 Prometheus 迁移的指南，以及从 Cortex 迁移的专门文档。迁移过程中，你需要确保现有数据的格式兼容，并规划好查询 API 的变化。

局限性：AGPL 许可与运维复杂度

Mimir 采用 AGPL-3.0 许可，这是一个重要的决策点。AGPL 要求如果你修改代码并提供网络服务，你必须开源修改后的版本。对于内部使用，这可能不是问题，但如果你的公司计划基于 Mimir 构建商业产品并对外提供服务，那么 AGPL 可能带来合规风险。另一个局限是，尽管单体模式易于启动，但生产环境的分布式部署并不简单。你需要管理多个组件、配置对象存储、处理复制因子和租户限额。此外，Mimir 的查询性能依赖于对象存储的延迟，对于需要亚秒级响应的实时查询，可能不如本地存储的方案。官方声称支持 1 亿活跃时间序列，但这是内部测试结果，实际规模取决于你的硬件和配置。

替代方案：Thanos 与 Cortex 的差异

与 Mimir 最直接的替代是 Thanos，它同样提供 Prometheus 长期存储和全局查询。关键差异在于：Thanos 采用 sidecar 模式，需要每个 Prometheus 实例旁边运行一个 sidecar 来上传数据，而 Mimir 是独立的集中式系统，Prometheus 通过 remote write 发送数据。这意味着 Thanos 更适合已有多个 Prometheus 实例且不想改变写入路径的环境，而 Mimir 更适合从零搭建或希望减少组件数量的场景。另一个替代是 Cortex，Mimir 实际上是 Cortex 的一个分支，但 Mimir 提供了更完整的运维工具和更积极的开发。如果你已经在用 Cortex，迁移到 Mimir 有官方指南，但如果你刚开始，选择 Mimir 可能更省心。

维护与升级成本：版本节奏与文档依赖

Mimir 的发布节奏看起来较快，例如 3.2.0 和 3.1.5 几乎同时发布，说明项目活跃。但这也意味着升级频繁，你需要跟踪每个版本的变更。官方文档区分了“最新版本”和“即将发布”的 main 分支，这有助于规划升级。维护成本方面，Mimir 打包了仪表盘、告警和 runbook，这可以降低运维负担，但前提是你熟悉 Grafana 的技术栈。许可方面，AGPL-3.0 没有商业使用限制，但如果你修改代码并分发，必须开源修改。这不像 Apache 2.0 那样宽松，因此对于某些企业可能是一个障碍。

编辑结论

Grafana Mimir 适合已经使用 Prometheus 且需要跨实例全局查询、长期存储或多团队隔离的团队，尤其是那些愿意接受 AGPL-3.0 许可约束并希望减少运维复杂度的用户。如果你只需要单实例的简单存储，或者对 AGPL 许可敏感，或者已有成熟的 Thanos 部署，那么 Mimir 可能不是最佳选择。在采用前，务必验证你的对象存储兼容性（如 S3 兼容实现的具体行为），并阅读官方架构文档确认多租户的隔离机制是否符合你的安全要求。最终，Mimir 的价值在于其一体化设计和内置的运维工具，但许可和迁移成本是必须权衡的现实因素。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes