共计 3260 个字符，预计需要花费 9 分钟才能阅读完成。
作者：Luc Perkins
Prometheus 是用于监控和可观察性的标准开源解决方案之一。Prometheus 于 2012 年起源于 SoundCloud，迅速获得广泛采用，后来成为首批 CNCF 项目之一，第二个毕业项目（仅次于 Kubernetes）。它被许多具有前瞻性思维的公司用于生产，包括 DigitalOcean、Fastly 和 Weaveworks 等重量级公司，并拥有自己的年度会议 PromCon。
Prometheus：强大但有意地限制
Prometheus 之所以成功，部分原因是核心 Prometheus 服务器及其各种补充程序，如 Alertmanager、Grafana 和导出生态系统，形成了一个引人注目的端到端解决方案，解决了一个至关重要的难题。但是，Prometheus 并没有提供你期望从一个成熟的“即服务”平台中获得的一些功能，例如多租户、身份验证和授权以及内置的长期存储。
Cortex 于 9 月作为沙箱项目加入 CNCF，是一个开源的 Prometheus 即服务平台，旨在填补这些空白，从而提供完整、安全、多租户的 Prometheus 体验。我会在以下说很多关于 Cortex 的，首先，让我们短暂地游览更熟悉的 Prometheus 世界。
为何选择 Prometheus？
作为 CNCF 开发者的倡导者，我有机会熟悉 Prometheus 社区和 Prometheus 作为工具（主要研究文档和 Prometheus Playground）。由于各种原因，它的巨大成功对我来说并不奇怪：
Prometheus 实例易于部署和管理。我特别喜欢近乎即时的配置重新加载，以及所有 Prometheus 组件都提供静态二进制文件。
Prometheus 提供了简单易用的指标展示格式，可以轻松编写自己的指标导出器。这种格式甚至通过 OpenMetrics 项目（最近也加入了 CNCF 沙箱）变成了开放标准。
Prometheus 提供了简单，但功能强大的基于标签的查询语言 PromQL，用于处理时间序列数据。我觉得 PromQL 非常直观。
为何选择 Prometheus 即服务？
早期，Prometheus 的核心工程师做出明智的决定，让 Prometheus 保持简洁和可组合。从一开始，Prometheus 设计成可以很好地完成一小部分工作，并与其他可选组件无缝协作（而不是让 Prometheus 负担过重，增加了一系列硬编码功能和集成）。以下是 Prometheus 设计范围外的一些内容：
长期存储 – 单个 Prometheus 实例提供持久存储时间序列数据，但它们不能作为分布式数据存储系统，不提供像具有跨节点复制和自动修复等功能。这意味着，耐久性保证仅限于单台机器。幸运的是，Prometheus 提供了一个远程写入 API，可用于将时间序列数据传输到其他系统。
全局数据视图 – 如上面要点所述，Prometheus 实例充当隔离数据存储单元。Prometheus 实例可以联邦，但这会给 Prometheus 设置增加很多复杂性，而且 Prometheus 不是设计为分布式数据库。这意味着，没有简单的途径来实现时间序列数据的单一，一致的“全局”视图。
多租户 – Prometheus 本身没有的租户概念。这意味着，它无法对特定于租户的数据访问和资源使用配额等事物，提供任何形式的细粒度控制。
为何选择 Cortex？
作为 Prometheus 即服务平台，Cortex 充分填补所有这些关键缺口，为即使是最苛刻的监控和可观察性使用案例，提供了完整的开箱即用解决方案。
它支持四种开箱即用的长期存储系统：AWS DynamoDB、AWS S3、Apache Cassandra 和 Google Cloud Bigtable。
它提供了 Prometheus 时间序列数据的全局视图，其中包括长期存储中的数据，极大地扩展了 PromQL 用于分析目的的有用性。
它的核心支持多租户。通过 Cortex 的所有 Prometheus 指标都与特定租户相关联。
Cortex 的架构
Cortex 具有基于服务的设计，其基本功能分为单个用途组件，可以独立扩展：
Distributor – 使用 Prometheus 的远程写入 API 处理由 Prometheus 实例写入 Cortex 的时间序列数据。传入数据会自动复制和分片，并且并行发送到多个 Cortex Ingester。
Ingester – 从 distributor 节点接收时间序列数据，然后将该数据写入长期存储后端，压缩数据到 Prometheus 块以提高效率。
Ruler – 执行规则并生成警报，将它们发送到 Alertmanager（Cortex 安装包括 Alertmanager）。
Querier – 处理来自客户端（包括 Grafana 仪表板）的 PromQL 查询，对短期时间序列数据和长期存储中的样本进行抽象。
这些组件每一个都可以独立管理，这是 Cortex 可扩展性和运营的关键。你可以在下面看到 Cortex 及与其交互的系统的基本图表：
如图所示，Cortex“完成”Prometheus 监控系统。要适应现有的 Prometheus 安装，你只需重新配置 Prometheus 实例以远程写入 Cortex 群集，Cortex 将处理其余部分。
多租户
单租户系统往往适用于小型用例和非生产环境，但对于拥有大量团队、用例和环境的大型组织而言，这些系统变得站不住脚（没有双关语意）。为了满足这些大型组织的严格要求，Cortex 不是作为附加组件或插件提供多租户，而是作为头等功能。
多租户被编织到 Cortex 的结构中。从 Prometheus 实例到达 Cortex 的所有时间序列数据，都在请求元数据中标记所属于的特定租户。从那里，该数据只能由同一个租户查询。警报也是多租户，每个租户都可以使用 Alertmanager 配置设定自己的警报。
从本质上讲，每个租户都有自己的系统“视图”，其自身以 Prometheus 为中心的世界。如果你以单租户的方式使用 Cortex，你可以随时扩展到无限大的租户群。
用例
经过几年的发展，Cortex 的用户倾向于分为两大类：
服务供应商构建托管的管理平台，提供监控和可观察性组件。例如，如果你正在构建像 Heroku 或 Google App Engine 这样的平台即服务产品，Cortex 使你能够为平台上运行的每个应用程序，提供 Prometheus 提供的全部功能，并处理每个应用程序（或者每个帐户或客户）作为系统的单独租户。Weave Cloud 和 Grafana Labs 使用 Cortex 使客户能够充分利用 Prometheus，他们是综合云平台的示例。
企业拥有许多内部客户，运行自己的应用程序、服务和“堆栈”。EA 和 StorageOS 是受益于 Cortex 的大型企业的例子。
Cortex、Prometheus 的生态系统和 CNCF
Cortex 有一些非常引人注目的技术特性，但在当前的行业氛围下，我也认为指出其开源特性也很重要：
Cortex 使用 Apache 2.0 许可授权，并由 CNCF 支持。
它仅与其他 Apache 2.0 CNCF 项目紧密耦合，没有与闭源、专有或特定于供应商技术的强链接。
项目合作者包括像 Goutham Veeramachaneni 和 Tom Wilkie 这样的 Prometheus 核心维护者，来自 Weaveworks、Grafana Labs、Platform9 等公司的工程师，以及其他大量投资于监控和可观察性领域的工程师。
Cortex 已经投入生产，为 Weave Cloud 和 Grafana Cloud 提供支持，这两个云产品（和核心贡献者）的成功关键取决于 Cortex 未来的发展轨迹。
通过在 CNCF 沙箱中添加 Cortex，现在 CNCF 保护伞下有三个与 Prometheus 相关的项目（包括 Prometheus 本身和 OpenMetrics）。我们知道监控和可观察性是云原生范式的重要组成部分，我们很高兴看到围绕 Prometheus 社区有机出现的一些核心基础的持续融合。Cortex 项目正在大力推进这项工作，我很兴奋 Prometheus 生态系统的 Prometheus 即服务分支成型。
