Cortex:多租户、可横向扩展的Prometheus即服务

62次阅读

共计 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 即服务分支成型。

正文完
 0