Prometheus 3.0 发布，7年磨一剑，哪些功能最令运维兴奋？

近日柏林，Prometheus 团队宣布 Prometheus 3.0 版本正式发布。据了解，这一版是 7 年来的首次重大更新，标志着一个重要里程碑。Prometheus 在这段时间内经历了巨大的变化，从最初的采用者项目变成云原生监控的标准组成部分，3.0 继续这一进程，增加了一些功能：

• 新界面

• 远程写入 2.0

• UTF-8 支持

• OTLP 支持

• • OTLP 数据接收

  • UTF-8 标准化

• 原生直方图

• 性能

• ……

现在介绍下比较重要的新功能：

1、新界面

全新的用户界面，该界面已默认启用：

主要是新增了类似 PromLens 风格的树状视图等功能。自测试版本发布以来，用户界面已支持 UTF-8 格式的指标名称和标签名称。

2、UTF-8 支持

Prometheus 现在默认在指标名称、标签名称和标签值中使用有效 UTF-8 字符。

如果任何一方不支持 UTF-8，指标名称将使用传统方法进行转义。为了检索 UTF-8 指标，可以使用新的引号语法编写 PromSQL 语句，或者手动指定 __name__ 名称。

目前只有 Go 客户端支持 UTF-8，其他语言很快添加。

3、OTLP支持

为了践行我们对 OpenTelemetry 的承诺，Prometheus 3.0 引入多项功能，以提升 OpenTelemetry 的互操作性。

OTLP 数据接收

Prometheus 可以配置为 OTLP Metrics 协议的原生接收器，通过 /api/v1/oltp/v1/metrics/ 端点接收 OTLP 指标数据。

UTF-8 标准化

得益于 Prometheus 3.0 对 UTF-8 的支持，用户现在可以存储和查询 OpenTelemetry 指标，而无需对指标名称和标签名称进行繁琐的修改（例如将点号改为下划线）。

这一改进显著减少了用户在 OpenTelemetry 语义约定或 SDK 中定义的指标与实际可查询内容之间的差异，从而降低了用户和相关工具的混淆。

为了实现 OTLP 数据接收的这一功能，Prometheus 3.0 实验性支持多种翻译策略。

有关详细信息，请参阅 Prometheus 配置中的 OTLP 部分。

4、性能

自 Prometheus 2.0 发布以来，我们在社区中取得的成就令人印象深刻。在 TSDB 模式下对 CPU 和内存使用效率的改进。

以下展示了在 8 核 CPU和 49 GB 可用内存的节点上，3个 Prometheus 版本的性能数据对比。

• 2.0.0（7年前）

• 2.18.0（4年前）

• 3.0.0（现在）

3.0 发布后

3.0版本新增了许多功能，中小企业基于开源的 Prometheus 进行监控落地，需要对部署架构进行调整，根据企业的情况来因地制宜。以下为一些常见问题：

高基数问题

高基数问题是指在 Prometheus 中使用过多的标签值，导致时间序列数量激增，从而引发性能问题甚至崩溃。例如，使用用户 ID 或公网 IP 作为标签值可能会导致高基数问题。为了避免这个问题，应该尽量减少标签的数量，并确保每个标签的值范围是有限的。

告警规则没有使用 for 字段

在定义告警规则时，如果没有使用 for 字段，可能会导致告警过于频繁地被触发。使用 for 字段可以设置一个持续时间，只有当条件在该时间内持续满足时才会触发告警，从而减少误报。

存储容量问题

Prometheus 默认将所有监控数据存储在本地磁盘上，随着监控数据量的增加，可能会导致存储空间不足。为了避免这个问题，可以考虑增加存储容量，或者使用更高效的存储引擎如 VictoriaMetrics 或 Thanos 等，以分布式方式存储和查询数据。

高可用性问题

Prometheus 默认是单节点部署，当节点故障或不可用时，监控数据将无法获取。为了避免这个问题，可以通过使用 Prometheus 的高可用模式或与其他存储和查询工具集成，如使用 Prometheus Operator 在 Kubernetes 集群上部署 Prometheus，或使用 Thanos 构建分布式监控系统。