Prometheus 兼容性调查见解
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
Prometheus 和 OpenTelemetry 是 CNCF 可观测性生态系统中两个最活跃和最受欢迎的项目。两个社区自 OpenTelemetry 早期以来就一直在合作，以改善两个项目之间的兼容性。OpenTelemetry Prometheus SIG 一直在领导这项工作，OpenTelemetry 和 Prometheus 的维护者们积极参与其中。
目前，有一项详细的实验性规范，描述了如何从OpenTelemetry 指标数据模型转换为Prometheus 指标格式。它已被用于实现 OpenTelemetry SDK 的 Prometheus(拉取)导出器、Prometheus 库的 OTLP导出、Prometheus 服务器的 OTLP摄取，以及 OpenTelemetry Collector 的Prometheus 接收器、Prometheus 远程写入导出器和Prometheus (拉取)导出器。
最难统一的领域之一是 OpenTelemetry 指标名称在导出到 Prometheus 时会被更改。如今，带有 `s` 单位的 OpenTelemetry 指标 `http.server.request.duration` 在 Prometheus 中被翻译为 `http_server_request_duration_seconds`。一些用户熟悉 Prometheus 的命名约定，并欣赏这种翻译与 Prometheus 生态系统中现有指标所提供的_一致性_。其他用户则会因为查询原始 OpenTelemetry 名称无结果而感到困惑。
Prometheus 正在为其 2024 年路线图的一部分，努力支持指标名称中的 UTF-8 字符，这可能会允许保留指标名称中的点。为了更好地理解用户希望他们的 Prometheus 查询体验是什么样的，OTel x Prometheus 工作组在OpenTelemetry 端用户 SIG的帮助下进行了一项调查。决定默认翻译方法是稳定兼容性规范的最后几个障碍之一。
该调查收到了 86 份回复（以及 5 份垃圾信息），其中包含许多有用的反馈。感谢所有参与者！
总体收获
- 大多数人（60%）倾向于在指标名称中保留点，而不是翻译成下划线。
- 略微多数（54%）倾向于在名称中包含单位，但只有 37% 认为单位应该是必需的。
- 倾向于在指标名称中包含单位的受访者也可能倾向于将点翻译成下划线。
- “单位和下划线”群组的最佳预测因素是 Prometheus 服务器专家和 SRE 角色。
- “无单位和点”群组的最佳预测因素是 OpenTelemetry 库专家和开发人员角色。
谁参加了调查
受访者主要来自大型（>1000 名员工）公司（52%），行业为科技（71%）。与 OpenTelemetry 相关的主题相比，受访者更倾向于认为自己是 Prometheus 相关主题的专家，并且在角色分布上是均衡的。几乎所有受访者（>90%）都将指标存储在 Prometheus 服务器或其他开源 Prometheus 后端，并且几乎所有人都使用 PromQL 查询他们的指标。
当前状态下的情绪
总的来说，受访者在 OpenTelemetry 与 Prometheus 的易用性问题上持中立态度，认为当前 OpenTelemetry 和 Prometheus 之间的翻译有些令人困惑。这与他们对单位或分隔符的看法一致。
点和下划线
OpenTelemetry 指定约定应使用点作为命名空间分隔符，并使用下划线作为“多单词点分隔的组件”（例如 `http.response.status_code`）之间的分隔符。另一方面，Prometheus 使用下划线作为其分隔符。
当前，当从 OpenTelemetry SDK 以 Prometheus 格式导出时，所有点都会被更改为下划线，以符合 Prometheus 的要求。我们想了解的是，那些使用这些导出器的 OpenTelemetry 用户是否更愿意保留原始指标名称中的点，还是更喜欢通过翻译成下划线来与现有的 Prometheus 指标保持一致。
在那些表示他们使用 OpenTelemetry 进行指标收集，并使用 PromQL 作为查询语言的用户中，60% 倾向于保留包含点的原始 OpenTelemetry 指标名称，而 40% 希望指标名称仅使用下划线以匹配 Prometheus 约定。
当我们询问具体的 PromQL 查询或警报示例时，结果与上述结果大致吻合。大约 42% 的用户仅选择了包含点的查询，约 39% 的用户仅选择了包含下划线的查询。最后的 19% 选择了一个包含点或下划线的混合查询，这表明他们可能对这两种方法都可以接受。
指标名称中的单位
OpenTelemetry 指定单位通常不应包含在指标名称中。Prometheus 约定建议将单位作为指标名称的后缀。OpenMetrics 更进一步，要求此单位后缀。目前，当从 OpenTelemetry SDK 以 Prometheus 格式导出时，单位会作为后缀添加到指标名称中。
在那些表示他们使用 OpenTelemetry 进行指标收集，并使用 PromQL 作为查询语言的用户中，37% 认为单位应作为指标名称的必需后缀，46% 认为单位不应添加到指标名称中。最后的 17% 倾向于在指标名称中包含单位，但不认为它应该是必需的。
当我们询问具体的 PromQL 查询或警报示例时，与上述问题相比，结果更倾向于在指标名称中包含单位。大约 45% 的用户仅选择了包含单位的查询，约 28% 的用户仅选择了不包含单位的查询。最后的 27% 选择了一个包含或不包含单位的混合查询，这表明他们可能对这两种方法都可以接受。
趋势
单位和分隔符偏好之间的相关性
偏好通常分为两类：一类是希望保留原始 OpenTelemetry 指标名称，包括点，并且没有单位后缀；另一类是倾向于更改名称以匹配 Prometheus 约定。57% 的希望强制在指标名称中包含单位的受访者，也希望将点更改为下划线。77% 的不希望在指标名称中包含单位的受访者，则偏好使用点作为指标名称。
群体差异
最能预测“强制单位和更改点为下划线”偏好的因素是 SRE 角色，以及成为 Prometheus 服务器配置专家。例如，88% 的 SRE 受访者倾向于将点翻译成下划线。
最能预测“保留 OpenTelemetry 名称（包含点，无单位）”偏好的因素是开发人员角色，以及成为 OpenTelemetry 库专家。例如，88% 的开发人员不倾向于将点翻译成下划线。
其他反馈
对所有受访者来说，最常见的挑战是 OpenTelemetry 仪器化代码的不稳定性以及对转换逻辑的困惑。偏好 OpenTelemetry 约定的受访者列出了 Prometheus 当前缺乏对 OpenTelemetry 概念（资源、范围、增量时态、单位元数据）的支持作为他们最显著的挑战。偏好 Prometheus 约定的受访者则认为 OpenTelemetry 的新概念令人困惑，并且对 OpenTelemetry 偏离了 Prometheus 的现有约定感到不满。
总的来说，这些反馈与 OpenTelemetry 和 Prometheus 社区的未来计划是一致的。OpenTelemetry 语义约定 SIG 正在努力稳定各种仪器化的约定。OpenTelemetry Prometheus 互操作性 SIG 正在努力将本次调查的结果纳入兼容性规范。Prometheus 社区有宏伟的计划来支持 OpenTelemetry 概念。
保持联系
再次感谢所有参与调查的人！您的反馈对我们指导 OpenTelemetry 的未来发展至关重要，并确保它能够继续满足您不断变化的需求。我们将在以下渠道发布未来的调查：
- #otel-sig-end-user Slack 频道 – 您也可以在此处联系我们！
- 终端用户资源页面
您可以在 #otel-prometheus-wg Slack 频道 提供进一步的反馈或参与有关 OpenTelemetry 和 Prometheus 互操作性的讨论。