摘要：文章探讨了OpenTelemetry在JavaScript环境中的挑战与改进方向，包括简化API、利用编译器优化、以及未来遥测技术的发展愿景，并提出基于事件的遥测表示作为改进的起点。

文章探讨了OpenTelemetry在JavaScript环境中的挑战与改进方向，包括简化API、利用编译器优化、以及未来遥测技术的发展愿景，并提出基于事件的遥测表示作为改进的起点。

译自：How to Make OpenTelemetry Better in the Browser

作者：Hazel Weakly

这是由两部分组成的第二部分。 阅读第 1 部分：

构建符合人体工学的JavaScript OpenTelemetry

在第 1 部分中，我介绍了一些在浏览器中使用 OpenTelemetry 很困难的原因，包括 JavaScript 的事件循环驱动设计与 OpenTelemetry 的 span 和 trace 模型不一致。 我将从上次结束的地方继续，分享另一种使 OpenTelemetry 更适合 JavaScript 的方法。 然后，我将介绍一些我希望看到的未来美好愿景，最后总结一些我们今天可以做出的直接改进。

现在，作为对我们上次结束的地方的回顾，请记住 trace、span、span 事件和日志都建立在相同的基础原语之上。 也就是说，它们基本上都只是事件。

不要让我思考

虽然解决 OpenTelemetry API 的设计可能会使检测更加符合人体工程学，但仅改进这一点并不足以改善人体工程学。

虽然解决 OpenTelemetry API 的设计可能会使检测更加符合人体工程学，但仅改进这一点并不足以改善人体工程学。 这是一个巨大的改进！ 但某些额外的功能将非常有帮助。 以一种最大程度地有用的方式设计和传播遥测仍然具有挑战性。

从其他类型的检测中汲取灵感可以为我们提供一些可能有用的想法：如果有一个函数可以向根 span 添加元数据，无论它在哪里？ 实现此函数将非常棘手，因为 span 的不变性对于 OpenTelemetry API 来说至关重要，违反它会破坏其他东西。

但是，另一种方法是对属性集进行持久引用值，然后可以对其进行修改。 这也可能会大大减少网络带宽。

进一步深入到灵感和想法中：如果有一个函数可以添加一个新的 span，但前提是父 span 尚不存在，或者以其他方式将内容附加到现有的 span 上？ 如果有一个函数可以获取数据并将其添加到每个子 span 中，甚至可以递归添加？ 如果有一种方法可以为单个函数编写检测，但当该函数在循环中调用时，该检测仍然有用？ 以及如何编写所有这些内容，而无需创建自定义处理器或自定义代码来以对你的用例有意义的方式将所有内容粘合在一起？

畅想未来

这为我带来了一个引人入胜的设计空间：如果我展望未来，想象遥测的未来，可能会有哪些可能性？

让我们进入这个假设的未来，想象一下：如果检测库在传统意义上并不真正存在，而你正在编写的代码实际上将在运行时生成并由编译器重写呢？ 你可以使用它来使检测代码非常轻量级和最小化，本质上是在编译时为你的应用程序定制构建的。 你可以使用编译器的信息来自动插入代码结构、添加生存期注释、控制流信息、调用堆栈数据，甚至可以重写遥测，使其对你的应用程序的需求更有意义。

这也可以促进非常高级的检测重写、最小化和压缩； 想象一下一种类似源代码映射的构造，你可以将二进制指针发送到某些常见的数据集。 你甚至可以想象自动规范化或反规范化遥测。 或者无需更改代码即可为流式传输和批量用例编写代码。 收集器可以为你滚动和展开遥测、折叠某些数据片段，甚至根据需要完全重写遥测树。

浏览器和语言运行时还可以通过确保正确的线程本地存储支持、上下文传播以及对类似异步范围内的上下文传播的支持来改进现有限制。

我希望看到一个拥有极其丰富的数据用于本地调试的世界，并且能够自然地减少这些数据以进行生产部署。

在“神奇”元数据对象中传播信息的能力也可能极大地促进构建这些类型的结构，这可以被认为类似于我之前提出的元数据引用思想。 如果语言运行时也包含显式的检测支持，那么可以以高度优化的方式编写该检测，这将使垃圾回收语言能够从低到零开销的检测中受益。 我觉得这令人兴奋，因为它是 OpenTelemetry 项目的实际目标，所以这种潜力并非遥不可及，但需要大量的协调。

此外，我希望看到一个拥有极其丰富的数据用于本地调试的世界，并且能够自然地减少这些数据以进行生产部署。 这样，在部署到远程服务器时，你就不会用冗长的调试数据炸毁一切，但在本地调试某些内容时，你可以轻松地一直深入到系统调用级别，甚至检查硬件以获得每个接口的极其精细的视图，无论抽象程度有多高。

仅仅因为一种语言是高级的，并不意味着你不应该能够在需要或想要时检查细节。 我认为我们可以在未来构建语言，从而在人体工程学上实现这一点，让你为生产环境检测代码，同时为开发获得丰富的检测，而无需对系统进行两次检测。 幸运的是，这里描述的大部分内容是即将到来的 OpenTelemetry 分析信号 的明确结果，所以我希望在未来几年看到很多进展。

让我们退后一步，回到现实。 思考未来是很有趣的，但我们今天可以从什么开始？

如果检测更紧密地嵌入到语言中，那么人们还可以想象其他元数据的统一集成，例如：调试信息、性能分析、功能标志、营销数据、安全事件和实验数据。 无需每个平台构建自己的 SDK 并需要自己的实现，它们可以使用更深入地构建到语言运行时本身中的检测功能。 你可以进行一次检测，并将该数据馈送到各种平台——从可观测性和监控到安全性和实验——所有这些都使用相同的代码。

我喜欢将未来想象成一个跨职能协作更容易实现，并且理解正在构建的复杂系统成为真正全公司范围的努力的未来。 我很乐意看到这种情况发生。

变得更好

所有这些充满希望和闪光的未来思考都很棒，但我们可能在几年甚至几十年内都无法真正看到这些类型的变化。 这也需要大量的协调，并且目前尚不清楚所涉及的社区是否真的希望这种情况发生。 因此，让我们退后一步，回到现实。 思考未来是很有趣的，但我们今天可以从什么开始？

这是我的想法：由于事件已经存在于 OpenTelemetry 中，并且由于几乎所有内容在底层都是事件，因此我们可以构建对“仅发送事件”作为 OpenTelemetry 规范的支持——可以将其视为 span、trace、日志和 span 事件的替代表示形式。 这将使我们能够自由地编写任何语言所需的任何库 SDK，同时保持与供应商的完全兼容性。 我们现在已经非常接近能够做到这一点，因为它所需要的只是一个修改后的 SDK 实现和一个修改后的有状态 OTel 收集器。 如果这两件事发生，供应商兼容性将保持不变，我们将有机会尝试基于事件的表示形式会是什么样子。

一些可观测性供应商已经在他们的产品中采用了这种遥测灵活性思维模式，尤其是在移动领域的供应商。 其中一个很好的例子是 Embrace 的用户旅程 功能，你可以从你已经收集的现有遥测数据创建自定义用户流程，而无需重构你的代码。 如果你有兴趣了解更多信息，你可以查看他们 即将举行的直播网络研讨会，该研讨会将于太平洋时间 9 月 16 日上午 10 点/美国东部时间下午 1 点举行。

遥测数据的基于事件的表示形式也将有助于在 trace、span、日志和 span 事件之间进行互操作。 它还将使我们能够使用相同的代码更轻松地从日志迁移到 trace。 然而，这并不意味着我认为我们将摆脱当前的 SDK。 它对于后端非常有用，并且也代表了一个做得很好的“立即付费”API，客户端会做更多的工作来处理遥测的有状态性质，作为交换，收集器可以是无状态的。 这意味着供应商很容易与 OpenTelemetry 兼容。

我很容易看到一个未来，人们可以选择“立即付费”模型（状态复杂性存在于客户端）与“稍后付费”模型（状态复杂性存在于收集器中），具体取决于哪种模型对他们的环境有意义。 大容量微服务可能会从“立即付费”模型中受益，而前端最适合“稍后付费”模型。

将两者结合在一起并能够将其全部绑定到一个连贯的上下文中将开启下一代对我们系统的理解。 我已经可以看到这种情况开始发生，这让我对 OpenTelemetry 在浏览器中的未来感到非常兴奋。

我在其他博客文章中提到过，云原生计算基金会 (CNCF) 为此设立了一个新的专门的浏览器特别兴趣小组 (SIG)，该小组正在积极致力于改进浏览器支持。 我认为这将带来令人着迷的发展，我真的很期待看到它有一天会变成什么样子。 如果你想了解更多关于浏览器 SIG 正在做的事情，请查看这个 点播网络研讨会。

来源：孙青讲一下