Prometheus 的问题
- 长期存储 - 单个Prometheus实例提供持久存储时间序列数据，但它们不能作为分布式数据存储系统，不提供像具有跨节点复制和自动修复等功能。这意味着，耐久性保证仅限于单台机器。幸运的是，Prometheus提供了一个远程写入API，可用于将时间序列数据传输到其他系统。
- 全局数据视图 - 如上面要点所述，Prometheus实例充当隔离数据存储单元。Prometheus实例可以联邦，但这会给Prometheus设置增加很多复杂性，而且Prometheus不是设计为分布式数据库。这意味着，没有简单的途径来实现时间序列数据的单一，一致的“全局”视图。
- 多租户 - Prometheus本身没有的租户概念。这意味着，它无法对特定于租户的数据访问和资源使用配额等事物，提供任何形式的细粒度控制。
Cortex
Mimir 的前身， Cortex 之前的维护者是 Grafana, 目前已经被 Grafana 放弃，转而维护 Mimir
- 它支持四种开箱即用的长期存储系统：AWS DynamoDB、AWS S3、Apache Cassandra和Google Cloud Bigtable。
- 它提供了Prometheus时间序列数据的全局视图，其中包括长期存储中的数据，极大地扩展了PromQL用于分析目的的有用性。
- 它的核心支持多租户。通过Cortex的所有Prometheus指标都与特定租户相关联。
Cortex具有基于服务的设计，其基本功能分为单个用途组件，可以独立扩展：
- Distributor - 使用Prometheus的远程写入API处理由Prometheus实例写入Cortex的时间序列数据。传入数据会自动复制和分片，并且并行发送到多个Cortex Ingester。
- Ingester - 从distributor节点接收时间序列数据，然后将该数据写入长期存储后端，压缩数据到Prometheus块以提高效率。
- Ruler - 执行规则并生成警报，将它们发送到Alertmanager（Cortex安装包括Alertmanager）。
- Querier - 处理来自客户端（包括Grafana仪表板）的PromQL查询，对短期时间序列数据和长期存储中的样本进行抽象。
这些组件每一个都可以独立管理
Mimir
Cortext 和 Mimir 的关系
首先 Mimir 确实是基于 Cortex 而来的，你可以理解它为 Cortex 的 2.0 版本，这也不难解释为啥 Mimir 开源的第一个版本就是 v2.0。
至于为什么这么做，我们可以从 HN 的讨论中看出原因：
- Cortex 有较大技术债，很难满足 Mimir 中的一些需求
- 开源协议的更改，更满足 Grafana 公司产品的发展，Cortex 属于 Apache-2.0 License, 而 Mimir 协议为 AGPLv3。
个人觉得协议的更改应该是决定因素，因为 AGPLv3 是目前 Grafana 主要使用的开源协议，可以参考【Grafana 开源协议更改 Q&A】 。