宣布 Prometheus 3.0

继最近在柏林 PromCon 上发布 Prometheus 3.0 测试版之后，Prometheus 团队激动地宣布 Prometheus 3.0 版本现已正式发布！

此最新版本标志着一个重要的里程碑，因为这是七年来第一个主要版本。Prometheus 在这段时间里取得了长足的进步，从一个早期采用者的项目发展成为云原生监控栈的标准组成部分。Prometheus 3.0 旨在通过增加一些令人兴奋的新功能，同时基本保持与之前版本的稳定性和兼容性，来延续这一旅程。

完整版 3.0 在测试版的基础上增加了一些新功能，并引入了一些额外的破坏性变更，我们将在本文中进行描述。

新增功能

以下是作为测试版发布的一部分以及此后添加的激动人心变更的摘要

全新 UI

Prometheus 3.0 的一大亮点是其全新 UI，该 UI 默认启用

New UI query page

UI 已完全重写，界面更简洁、外观和感觉更现代化，新增了诸如 PromLens 风格的树状视图等功能，并将通过使用更现代的技术栈来简化未来的维护工作。

要了解有关新 UI 的更多一般信息，请参阅Julius 在 PromLabs 博客上的详细文章。用户可以通过使用 old-ui 功能标志暂时启用旧 UI。

由于新 UI 尚未经过实战考验，因此可能仍然存在错误。如果您发现任何错误，请在 GitHub 上报告。

自测试版发布以来，用户界面已更新，支持 UTF-8 指标和标签名称。

New UTF-8 UI

远程写入 2.0

远程写入 2.0 在之前的协议版本上进行了迭代，增加了对许多新元素的原生支持，包括元数据、范例、创建时间戳和原生直方图。它还使用字符串实习（string interning）来减小压缩和解压缩时的有效载荷大小和 CPU 使用率。对部分写入的处理得到了改进，以便在此发生时为客户端提供更多详细信息。更多详细信息可在此处找到。

UTF-8 支持

Prometheus 现在默认允许在指标和标签名称中使用所有有效的 UTF-8 字符，以及在标签值中使用 UTF-8 字符，这与 2.x 版本一致。

用户需要确保其指标生产者配置为传递 UTF-8 名称，如果任何一方不支持 UTF-8，指标名称将使用传统的下划线替换方法进行转义。PromQL 查询可以使用新的引用语法来检索 UTF-8 指标，或者用户可以手动指定 __name__ 标签名称。

目前只有 Go 客户端库已更新以支持 UTF-8，但对其他语言的支持将很快添加。

OTLP 支持

为了与我们对 OpenTelemetry 的承诺保持一致，Prometheus 3.0 提供了几项新功能，以改善与 OpenTelemetry 的互操作性。

OTLP 摄取

Prometheus 可以配置为 OTLP Metrics 协议的原生接收器，在 /api/v1/otlp/v1/metrics 端点接收 OTLP 指标。

有关将 OTLP 指标流量消耗到 Prometheus 中的最佳实践，请参阅我们的指南。

UTF-8 标准化

借助 Prometheus 3.0，得益于 UTF-8 支持，用户可以存储和查询 OpenTelemetry 指标，而无需对指标和标签名称进行恼人的更改，例如将点更改为下划线。

值得注意的是，这使得用户和工具对于 OpenTelemetry 语义约定或 SDK 中定义的内容与实际可查询内容之间的差异困惑更少。

为了实现 OTLP 摄取的这一点，Prometheus 3.0 具有对不同转换策略的实验性支持。有关详细信息，请参阅Prometheus 配置中的 otlp 部分。

注意： 虽然“NoUTF8EscapingWithSuffixes”策略允许特殊字符，但它仍然会添加必需的后缀以获得最佳体验。有关未来启用无后缀工作的提案，请参阅此提案。

原生直方图

原生直方图是 Prometheus 的一种指标类型，它提供了一种比经典直方图效率更高、成本更低的替代方案。原生直方图不像经典直方图那样需要根据数据集选择（并可能更新）bucket 边界，而是具有基于指数增长的预设 bucket 边界。

原生直方图仍处于实验阶段，尚未默认启用，可以通过传递 --enable-feature=native-histograms 来开启。原生直方图的某些方面，例如文本格式和访问器函数/运算符，仍在积极设计中。

破坏性变更

Prometheus 社区致力于在主要版本中不破坏现有功能。随着新主要版本的发布，我们借此机会清理了一些长期存在但很小的问题。换句话说，Prometheus 3.0 包含一些破坏性变更。这包括对功能标志、配置文件、PromQL 和抓取协议的更改。

请阅读迁移指南，了解您的设置是否受到影响以及需要采取哪些措施。

性能

看到社区自 Prometheus 2.0 以来取得的成就令人印象深刻。我们都喜欢数字，因此让我们庆祝我们在 TSDB 模式下对 CPU 和内存使用效率所做的改进。下面您可以看到在具有 8 个 CPU 和 49 GB 可分配内存的节点上，3 个 Prometheus 版本之间的性能数据。

  • 2.0.0（7 年前）
  • 2.18.0（4 年前）
  • 3.0.0（现在）

Memory bytes

CPU seconds

更令人印象深刻的是，这些数据是使用我们的prombench 宏基准测试获得的，该基准测试使用相同的 PromQL 查询、配置和环境——突显了即使是 3.0 版本，核心功能也保持了向后兼容性和稳定性。

下一步计划

Prometheus 及其生态系统中仍有大量激动人心的功能和改进可以实现。以下是一个非详尽列表，旨在让您感到兴奋，并... 希望能激励您做出贡献并加入我们！

  • 新的、更具包容性的治理
  • 更多 OpenTelemetry 兼容性和功能
  • OpenMetrics 2.0，现由 Prometheus 治理！
  • 原生直方图稳定性（并支持自定义 buckets！）
  • 更多优化！
  • 更多 SDK 和工具中对 UTF-8 的支持覆盖

尝试一下！

您可以通过从我们的官方二进制文件和容器镜像下载 Prometheus 3.0 来尝试。

如果您正从 Prometheus 2.x 升级，请查看迁移指南，以获取有关您需要进行任何调整的更多信息。请注意，我们强烈建议在升级到 v3.0 之前升级到 v2.55。从 v3.0 回滚到 v2.55 是可能的，但不能回滚到更早的版本。

一如既往，我们欢迎社区的反馈和贡献！