Jaeger和OpenTelemetry

作者：Yuri Shkuro

最近，OpenTelemetry宣布成为CNCF新的沙箱项目，由OpenTracing和OpenCensus[1]、[2]、[3]、[4]合并而成。已经有几个人问我，OpenTelemetry对Jaeger项目（在CNCF孵化阶段）意味着什么，以及它是否会取代Jaeger。我将在这篇文章中尝试回答这些问题。

TLDR;OpenTelemetry对于Jaeger项目来说是个好消息！

为什么需要OpenTelemetry

从2015年秋季Zipkin研讨会开始，我就一直致力于OpenTracing项目。我们刚刚开始在Uber上部署分布式跟踪，我知道我们需要一个开放的、与供应商无关的API来整合到Uber快速增长的微服务生态系统的源代码中。今天，OpenTracing API支持超过9种语言，得到了供应商的广泛支持，并与各种开源项目集成了100多个（https://opentracing.io/registry）。

OpenCensus是谷歌用于收集跟踪和度量数据的内部Census库的开源版。它采用了一种不同的方法，为捕捉可观测性信号提供了一个具体的、带主观意见的实现。通过使用“附带电池”的方法，它比作为二进制文件，如数据库引擎、Kubernetes组件等，提供的软件的OpenTracing具有优势，因为二进制文件可以链接到一个已知的实现，而不是使用OpenTracing方法所需的后期绑定到具体的跟踪程序。缺点是，由于OpenCensus API是与实现紧密耦合的，所以即使在用户需要的时候，也很难甚至不可能将检测绑定到不同的实现。

这两个项目的目标都是使现代应用程序的可观察性更容易，并加速软件行业广泛采用分布式跟踪，但是它们之间的竞争，通常这是一件非常健康的事情，却实现了完全相反的结果。面对两个相互竞争的标准，最终用户只能选择其中之一，就像“VHS vs. Betamax”。

事实证明，这两个项目的方法是互补的，而不是相互矛盾的。我们没有理由不能同时拥有抽象的、与供应商无关的API和受良好支持的默认实现。欢迎来到OpenTelemetry！

OpenTelemetry最大的承诺不是解决OpenTracing和OpenCensus没有解决的一些新问题。相反，这是对单一标准的承诺，而不是两个标准的竞争。为了实现这一目标，第一个GA版本的OpenTelemetry库故意将范围缩小到：

• 通过垫片（shim）向后兼容OpenTracing和OpenCensus测仪
• 避免引入两个原来项目中没有的新特性

OpenTelemetry最大的承诺是一个单一的可观察性标准，而不是两个相互竞争的标准。

上下文传播作为底层

我最近写了一篇关于分布式上下文传播对于现代分布式系统的重要性的文章。我们都知道没有它跟踪就不能工作，但是它不是惟一可以从上下文传播中获益的应用程序。许多流行的遥测API（度量和日志记录）都不支持上下文感知，这使得我的文章中描述的一些用例非常难以支持，尤其是在必须显式访问上下文的Go等语言中。值得称道的是，OpenCensus项目一直希望遥测API能够感知上下文，而在OpenTracing中，通用上下文传播（也称为“包袱，baggage”）被内置到跟踪API中，这使得从度量API中使用变得很困难。合并这两个项目的一个重要副作用是协议将上下文传播分离到一个底层API层，其他遥测API使用该层访问上下文数据。我写了一个“上下文传播层”的设计方案，它包含了更多的细节。

上下文传播和遥测API的分层

OpenTelemetry和Jaeger

与其他跟踪后端不同，Jaeger项目从来没有打算解决代码测仪问题。通过提供与OpenTracing兼容的tracer库，我们能够利用现有OpenTracing兼容工具的丰富生态系统，并集中精力构建跟踪后端、可视化工具和数据挖掘技术。

该模型仍然适用于面向测仪领域的OpenTelemetry。最终用户将能够使用OpenTelemetry SDK来测仪他们的应用程序或框架，并使用Jaeger作为跟踪数据的后端。

接下来的问题是Jaeger tracer（客户端库）的未来，它确实与OpenTelemetry在相同的问题领域。短期内，可以更改Jaeger客户机库来实现OpenTelemetry API。为了支持新的测仪风格，同时保留Jaeger特有的现有功能，例如自适应采样，这可能是必要的。

从长远来看，我们将认真考虑冻结Jaeger客户端库的开发，并将其独特的特性移植到OpenTelemetry默认实现，通过贡献到上游，或者作为插件。开发和维护多种语言的客户端库是项目资源的一项重大投资，最好将其用于构建新的后端特性。

那么OpenCensus代理/收集器呢？

即使对于OpenCensus库，“附带电池”方法也并不总是有效，因为它们仍然需要配置特定的导出插件，以便将数据发送到具体的跟踪后端，比如Jaeger或Zipkin。为了解决这个问题，OpenCensus项目开始开发两个后端组件代理（agent）和收集器（collector），它们扮演的角色与Jaeger的agent和collector几乎相同：

agent是一个sidecar/host agent，它以标准格式接收来自客户端库的遥测数据，并将其转发给collector；

collector将数据转换为特定跟踪后端可以理解的格式，并将其发送到那里。OpenCensus收集器还能够执行基于尾部的采样。

这两个组件与Jaeger后端组件的功能有很大的重叠。然而，它们仍然局限于数据收集的问题领域，而不是跟踪存储或后处理。这意味着，在未来，我们可能还会强烈考虑不支持Jaeger代理和收集器组件，而是部署OpenTelemetry的组件。主要的问题是OpenTelemetry组件是否能够支持Jaeger组件提供的其他特性，比如自适应采样。

结论

正如我在开始时所说的，OpenTelemetry项目对于Jaeger项目来说是一个好消息，因为它们在问题领域方面是非常互补的。在存在重叠的领域，即客户端库、代理和收集器，我们计划与OpenTelemetry合作，并在理想情况下摒弃Jaeger组件，这样我们就不必浪费时间维护冗余软件。

参考文献

1. OpenTracing和OpenCensus正在合并（OpenTracing blog）
2. OpenTelemetry的简史（到目前为止）（CNCF博客）
3. OpenTelemetry：小组讨论及问答（KubeCon EU视频）
4. OpenTelemetry：向后兼容OpenTracing和OpenCensus（KubeCon EU视频）

https://medium.com/opentracing/a-roadmap-to-convergence-b074e5815289

https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/

https://www.youtube.com/watch?v=IdYZphA5S7s

https://www.youtube.com/watch?v=mvWwSkBq9sY