Prometheus 应如何处理 OpenTelemetry 资源属性？ - 一项用户体验研究报告

作者：Victoria Nduka | 2025年7月22日，星期二

2025年5月29日，我通过Linux Foundation 导师计划结束了我在 Prometheus 的指导项目。我的项目重点是理解 Prometheus 如何处理 OpenTelemetry 资源属性，以及如何改善用户在这方面的体验。我的任务是进行用户研究，以了解用户对此挑战的看法。在三个月内，我进行了用户和利益相关者访谈，进行了一项调查，并分析了研究结果。

在本文中，我将分享我如何进行研究、我发现了什么，以及相关社区未来可以如何发展。

项目背景

OpenTelemetry (OTel) 有一个名为“资源属性”的东西，它包含了关于指标来源的额外信息，例如生成指标的服务、主机或环境。Prometheus，一个时间序列数据库，使用标签来标识和查询指标。如果将资源属性转换为标签，可能会导致所谓的“基数爆炸”，即创建过多的唯一组合，从而使系统不堪重负。当属性频繁更改或包含大量唯一值（如用户 ID 或 pod 名称）时，通常会发生这种情况。

目前，处理此挑战主要有三种方法：

将所有资源属性映射为标签：这会导致基数爆炸问题，尤其是在属性数量庞大或属性值频繁变化的应用程序中。
选择性提升：用户手动选择哪些资源属性足够重要，可以转换为 Prometheus 中的标签。
目标信息模式：将所有资源属性放入一个名为 `target_info` 的单独指标中。当用户需要查询涉及特定资源属性的指标时，他们必须在目标信息和实际指标之间执行“连接”。

这些在技术上并非糟糕的解决方案，但它们并非最佳用户体验。因此，我进行了这项研究，以了解 Prometheus 维护者可能遗漏了用户体验方面的哪些方面。

研究目标是：

了解工程师目前如何将 OpenTelemetry 资源属性与 Prometheus 结合使用
识别当前集成中的痛点
发现用户对资源属性应如何表示的期望

研究方法

我的研究方法结合了定性和定量研究。我首先进行了利益相关者访谈，以了解历史背景并评估开放利益相关者对我的研究可能带来的变化的接受程度。我交流的利益相关者代表了各种角色，从项目创始人和联合创始人，到具有历史背景的长期维护者，以及其他更直接参与资源属性处理相关挑战的人员。

接下来，我进行了用户访谈，直接听取了实际使用这些工具的人的意见。最后，我通过一项调查来接触更广泛的受众并验证我在访谈中听到的内容。

利益相关者访谈见解

我与 6 位利益相关者进行了交谈——每项项目 3 位。

Prometheus 利益相关者

Julius Volz – Prometheus 联合创始人
Beorn Rabestein – Prometheus 长期维护者
Richard Hartmann – OpenMetrics 联合创始人兼 Prometheus 维护者

OpenTelemetry 利益相关者

Juraci Paixão Kröhling – OpenTelemetry 治理委员会成员
Josh Suereth – OpenTelemetry 技术委员会成员
Austin Parker – OpenTelemetry 联合创始人兼治理委员会成员

我的利益相关者谈话揭示了几项有趣的发现：

Prometheus 和 OpenTelemetry 社区的沟通一直不畅，这阻碍了他们早期合作。
目前存在的许多互操作性问题源于这两个项目所建立的不同哲学和技术基础。
“如果我们考虑到探索性场景或用例，那么我们可以证明 OpenTelemetry 背后的许多设计决策是合理的。如果我们考虑到大规模基础设施的指标和扩展、监控，那么 Prometheus 的设计决策也是合理的。所以两者都有很好的论据。” — Juraci Paixão Kröhling
“我认为最大的（互操作性问题之一）是推拉模型之间的差异。” — Julius Volz
Julius 随后详细说明，他的担忧不仅仅是传递机制本身。用他的话说：
“使用 OTLP 将指标推送到 Prometheus 的最大缺点之一是，您最终会放弃 Prometheus 作为监控系统的核心功能之一：其基于动态服务发现信息的拉取式指标收集模型（因此 Prometheus 始终知道当前应该存在哪些目标），以及由此产生的通过为每个目标抓取生成的合成‘up’指标进行的自动目标健康监控。”
双方都认识到将用户需求放在首位的重要性，同时也要保持一些不可动摇的原则（例如，Prometheus 保持其拉取模型，不疏远现有用户）。

从访谈中一个关键的收获是，我意识到当前的互操作性问题不是失败，而是不同社区在不同时间解决不同问题的自然结果。很高兴看到这两个项目现在正在合作以改善用户体验。

用户访谈见解

用户访谈与利益相关者对话一样富有启发性。我原本打算采访大约 10 位用户（承认有点雄心勃勃），但最终成功采访了 7 位，他们都分享了非常有帮助的观点。

用户分享的最突出的痛点是当前集成中执行连接的复杂性。另一个被提及的问题是由于字符集限制导致的指标名称不匹配，但我了解到这个问题后来已得到解决，因为最近的 Prometheus 版本现在支持 UTF-8 字符（尽管这引入了在 PromQL 中使用更笨拙的带引号选择器语法的需求）。

在心智模型方面，许多用户（包括受访者和调查对象）不区分资源属性和 Prometheus 标签。他们倾向于认为它们是同一件事。

“我期望资源属性通常与附加到跟踪器、指标的属性一样被对待……我不会在它们之间划界。” — 访谈参与者 1

我还了解到人们为处理特定用例中的资源属性问题而使用的各种变通方法。一些人将选定的资源属性提升为标签，另一些人在 OpenTelemetry Collector 层面处理转换以避免在 Prometheus 中处理，还有一些人转换了所有属性，但这通常只在属性数量很少时才会这样做。

调查问卷见解

调查问卷帮助我量化了我在访谈中听到的内容，并接触到了更广泛的受众。截至撰写本文时，我们收到了 134 份回复，其中 61 份来自我们的目标群体——一起使用 OTel 和 Prometheus 的人。

以下是主要发现：

用户不认为资源属性与常规标签不同，但当前的实现将它们视为独立的元数据。
复杂的连接语法是采用的主要障碍，普通开发者无法编写访问资源属性的基本查询。
手动提升属性会产生操作开销，而这种开销与团队规模和复杂性的增长不成比例。
78% 的受访者认为文档缺失是他们在资源属性使用中的一个挑战。

A bar chart showing challenges with OpenTelemetry resource attributes in Prometheus

调查问卷的模式与我定性研究的结果一致。有关详细结果，请参阅匿名调查回复。

我没有预料到的学习成果（但确实学到了）

我开始这项研究是为了了解用户在处理资源属性方面的痛点，但我发现了一些意想不到的重要发现。

其中最令人惊讶的发现之一是，OpenTelemetry 的资源检测功能允许用户使用有时被称为“望远镜”的概念模式，根据相关性选择性地保留或丢弃资源属性。尽管它有潜力，但许多用户甚至一些 Prometheus 社区成员似乎都不知道它。这种缺乏意识可能导致了“连接”模式的采用，而这种模式后来被证明是有问题的。

这突显了一个更广泛的问题：文档和教育差距是一个主要障碍。在我们的调查中，78% 的受访者将文档差距列为挑战。

另一个关键的认识是，早期的集成决策（如依赖于连接）是在未能完全了解每个工具的功能的情况下做出的，这是 Prometheus 和 OpenTelemetry 社区早期缺乏协作和沟通的不可避免的后果。

致谢

如果没有对我的了不起的导师的感谢，这篇文章将不完整：Amy Super，Andrej Kiripolsky，以及Arthur Silva Sens——感谢你们信任我承担这个具有挑战性的项目，并如此深切地关心我的职业发展。你们才是真正的明星。

感谢所有提供时间的利益相关者和用户：感谢你们参与这项工作并信任我提供诚实的反馈。你们的见解使这项研究具有意义。

我的下一步

我很高兴能继续在用户体验和云原生系统交叉的领域工作。如果您知道有与本次指导项目类似的职位，我很乐意收到您的来信！我工作努力——问问我的导师就知道了。

最后修改于 2025 年 7 月 22 日：[博客] 关于 Prometheus 中 OpenTelemetry 资源属性的用户体验研究结果 (#7357) (79878928)