OpenTelemetry：统一应用程序和基础设施的可观察性

在与prometheus长期维护者goutham veeramachaneni的问答中，他剖析了opentelemetry (otel) 对可观察性领域的影响。otel促进了遥测数据的标准化，推动了数据收集器和工作流程的创新，弥合了应用程序和基础设施监控之间的鸿沟。veeramachaneni深入分析了不断发展的生态系统、未来的挑战以及开发人员通过otel构建更高效遥测数据管道的可能性。

在这次富有洞察力的问答中，长期担任Prometheus维护者和Grafana Labs产品经理的Goutham Veeramachaneni分享了他对OpenTelemetry (OTel) 在可观察性领域的变革性影响的独特见解 。Veeramachaneni 讨论了 OTel 如何标准化遥测数据并启发新的开源数据收集器和工作流程，以弥合应用程序和基础设施监控之间的差距。他对不断发展的生态系统、未来的挑战以及开发人员在编写更有效的遥测数据管道方面的激动人心的可能性提供了宝贵的见解。

问：作为 Prometheus 的长期维护者，您如何看待 OpenTelemetry 对市场产生的整体影响？

答： 它让开发人员和平台团队对其数据拥有了更大的所有权。它为他们提供了前所未有的灵活性和自由。以前，由于没有遥测数据的通用开放标准，专有供应商的捕鼠器被设计成使迁移到其他解决方案变得极其困难，这太疯狂了。这些供应商没有太多的创新或竞争动力，因为他们已经设计了如此有效的捕鼠器来锁定用户。他们说出自己的协议并收集自己的指标，但没有标准化。OpenTelemetry 已经迫使整个市场在 OTLP 协议及其 SDK 和 API 生态系统上实现标准化。这剥夺了供应商的权力，并创建了一个动态、开放的标准，每个人都可以合作——这正在推动大量创新。

问：过去一年中，您看到 OTel 最令人兴奋的新进展是什么？

答：我很高兴看到 Prometheus 和 OTel 的合作，以及将应用程序可观察性提升到与基础设施可观察性相同的标准化和一致性水平的所有势头。Prometheus 是基础设施可观察性中的一个重要组成部分——每个人都直接使用它，或者从供应商那里使用 Prometheus 的某个版本。Prometheus 如此受欢迎的原因之一是几乎每个基础设施组件都有一个导出器，并且有如此庞大的社区支持它。然而，在 OTel 出现之前，应用程序可观察性中不存在这样的标准化和创新速度，因为您需要花费大量精力来创建自动检测代理，并且只有拥有 20 人团队开发这些检测代理的知名供应商才具备这种技能。因此，应用程序可观察性拥有所有这些用于指标收集的专有协议和方法，并且没有标准化。但现在 OTel 通过引入一个可以监控应用程序的标准创造了立足点，并且同样为所有流行语言实施了该标准。

问：应用程序和基础设施可观察性结合在一起意味着什么？我们需要做些什么才能实现这一目标？

答： 嗯，我们已经有一个标准，就像Prometheus及其导出器一样，现在在应用程序可观察性世界中，您拥有所有这些 SDK 和自动仪表代理来生成 OpenTelemetry。Prometheus 在过去一年中取得了很大进展，开始提取 OTel 数据，因此基础设施和应用程序指标现在并排位于同一系统中。Prometheus 3.0 将于今年晚些时候推出，其主要功能和重点领域之一就是对 OpenTelemetry 的支持。

然而，故事并没有结束。您需要能够轻松地将指标关联在一起。例如，您需要能够将 RED 指标中的错误峰值与应用程序正在运行的节点上的 CPU 饱和度联系起来。这很棘手，因为 Prometheus 和 OpenTelemetry 的约定尚未对齐。我相信这是社区明年将关注的重点：确保您能够无缝关联和导航使用 OTel 进行应用程序监控和使用 Prometheus 进行基础设施监控这两个世界之间的数据。

最后，还有一个“收集”这些数据的症结。虽然您可以使用 OpenTelmetry Collector 收集 Prometheus 指标，但您需要将 Prometheus 转换为 OTLP，然后再转换回 Prometheus 数据（因为数据存储是 Prometheus）。这在当今具有很高的 CPU 开销，这是我们想要优化的。这也是我对 Grafana 的新开源收集器 Alloy 感到兴奋的原因。Alloy 来自 Prometheus 优先的传统，并嵌入了多个基础 Prometheus 导出器。它也是一个 OTel Collector 发行版，支持高效收集和处理 OTel 数据。它之所以出彩，是因为如果您正在收集 Prometheus 数据并且您的最终目的地也是 Prometheus，那么它可以避免在管道中转换为 OTLP 的 CPU 成本。

这是开放标准的优点之一，也是构建的稳定基础 — 您可以直接使用 OTel 收集器，也可以使用经过优化的新收集器（如 Alloy），它使 Prometheus 和 OTLP 能够更无缝地协同工作，或者您可以尝试任何其他收集器。OTel 创造了这个买方市场，开发人员可以自由选择使用哪些可观察性工具，同时知道他们拥有自己的遥测数据，并且 OTel 本身正在承担语言支持的重任。

问：您能描述一下应用程序和基础设施可观察性之间的历史脱节吗？

答：今天，如果您查看要调试的系统，就会发现它有基础设施——MySQL 、 Postgres、数据库、节点级数据（例如我正在运行的主机以及它所运行的内存和 CPU），然后您正在其上运行应用程序 / 容器。当您打开一个页面时，用户会看到错误——突然间，您就会拥有一组仪表板，其中显示了应用程序列表以及每个应用程序的执行情况。很容易看到错误发生在哪里（例如，在 MySQL 中），但从那里找出 MySQL 的问题并不容易。因为应用程序使用的是 OpenTelemetry 指标，而 MySQL 使用的是 Prometheus 指标——两者之间没有标准化。需要大量的专业知识才能找到正在运行的服务的正确实例并进行这些类型的关联，而随着我们看到 Prometheus 和 OpenTelemetry 之间更深层次的原生集成，这将变得更加容易。

问：您认为 OTel 未来将重点解决哪些遥测数据方面尚未解决的问题领域？

答：要实现标准化的目标，你必须在许多人和团体之间达成共识——这是 OTel 所取得的成就中令人瞩目的一点。一旦规范确定，执行和创新就会变得容易。我看到一些领域，OpenTelemetry 不可避免地会对遥测数据标准化产生类似的影响，但事情还处于早期阶段，达成共识仍是一条出路。前端监控用户监控就是一个例子。在日志记录方面，我们需要看到更多数据库和日志记录系统采用 OTel 规范。LLM 的语义约定仍然主要是专有的。观察消息队列和构建在其上的应用程序仍处于早期阶段。CI/CD 领域有大量创新，需要更好的指标来了解构建需要多长时间——这是 OTel 的另一个令人兴奋的机会领域。 

以上就是OpenTelemetry：统一应用程序和基础设施的可观察性的详细内容，更多请关注叮当号网其它相关文章！