今天，我们启动了 Prometheus 一致性计划，旨在确保 Prometheus 监控领域中不同项目和供应商之间的互操作性。虽然法律文件仍需最终确定，但我们已经进行了测试，并将以下内容视为我们的第一轮结果。作为此次发布的一部分，Julius Volz 更新了他的 PromQL 测试结果 。

简单回顾一下：该计划被称为 Prometheus 一致性 (Conformance) 计划，软件可以遵循 (compliant) 特定的测试，从而得出一个兼容性 (compatibility) 评级。这套术语可能看起来复杂，但它使我们能够讨论这个话题时避免使用冗长的词组。

前言

新类别

我们发现，要理清什么需要应用于哪种软件是相当困难的。为了帮助整理思路，我们创建了一份概述 ，引入了四个新的类别来对软件进行分类：

• 指标暴露器 (Metrics Exposers)
• 代理/收集器 (Agents/Collectors)
• Prometheus 存储后端 (Prometheus Storage Backends)
• 完全 Prometheus 兼容性 (Full Prometheus Compatibility)

号召行动

我们非常欢迎反馈。也许有悖直觉，但我们希望由社区，而不仅仅是 Prometheus 团队，来塑造这项工作。为了实现这一目标，我们将在 Prometheus 内部成立一个一致性工作组 (WG Conformance)。与文档工作组 (WG Docs) 和存储工作组 (WG Storage) 一样，这些工作组将是公开的，我们积极邀请大家参与。

正如我们最近提到的 ，Prometheus 的维护者与使用者比例出奇地低，甚至可以说是惊人地低。换句话说，我们希望围绕 Prometheus 兼容性的经济激励能吸引供应商投入资源，与我们一同构建测试。如果你一直想在工作时间为 Prometheus 做出贡献，这可能就是一条途径；而且这条途径会让你接触到 Prometheus 的许多高度相关的方面。有多种方式可以与我们联系。

注册参与测试

如果你想注册参与测试，可以使用相同的沟通渠道与我们联系。一旦法律文件准备就绪，我们会将联系信息和合同操作移交给 CNCF。

测试结果

完全 Prometheus 兼容性

我们知道我们想要构建哪些测试，但目前还未完成。如前所述，以此来要求项目或供应商是不公平的。因此，测试桩 (test shims) 被定义为已通过。目前，例如Julius 本周进行的 PromQL 测试 仍带有半手动的性质，这意味着在大多数情况下，作为 PromQL 测试的一部分，Julius 测试了通过 Prometheus Remote Write 发送数据。我们在这里以多种方式复用了他的结果。这种情况很快会得到梳理，更多来自不同角度的测试将不断提高要求，从而增强最终用户的信心。

将项目和“即服务”(aaS) 产品分为两组来看待是合理的。

项目

通过

• Cortex 1.10.0
• M3 1.3.0
• Promscale 0.6.2
• Thanos 0.23.1

未通过

VictoriaMetrics 1.67.0 未通过，并且无意通过 。本着增强最终用户信心的精神，我们决定追踪他们的结果，因为他们将自己定位为 Prometheus 的直接替代品。

即服务 (aaS)

通过

• Chronosphere
• Grafana Cloud

未通过

• Amazon Managed Service for Prometheus
• Google Cloud Managed Service for Prometheus
• New Relic
• Sysdig Monitor

注：由于 Amazon Managed Service for Prometheus 与 Grafana Cloud 一样都基于 Cortex，我们预计它们在下一个更新周期后会通过测试。

代理/收集器

通过

• Grafana Agent 0.19.0
• OpenTelemetry Collector 0.37.0
• Prometheus 2.30.3

未通过

• Telegraf 1.20.2
• Timber Vector 0.16.1
• VictoriaMetrics Agent 1.67.0

注：我们测试的是 Vector 0.16.1 而不是 0.17.0，因为 0.17.0 没有提供二进制下载，而我们目前的测试工具链需要二进制文件。