介绍OpenTelemetry（第1/2部分）

作者：Ran Ribenzaft，Epsagon联合创始人和首席执行官。嘉宾文章最初在Epsagon博客上发表。

https://epsagon.com/blog/tools/introduction-to-opentelemetry-overview/

OpenTelemetry是一个令人兴奋的新型可观察生态系统，背后有许多领先的监测公司。它是CNCF支持的与提供者无关的可观察性解决方案，代表了继OpenCensus和OpenTracing之后，开放可观察性的第三次演进。OpenTelemetry支持用于跟踪和指标的API，它为许多编程语言提供了丰富的自动检测（instrumentation）和SDK，旨在支持与供应商无关的检测，使用OpenTelemetry收集器让你避免厂商锁定。

本文提供了关于OpenTelemetry及其主要组件的技术概述：指标、跟踪、SDK及其收集器代理。它解释了为什么一种新的遥测方法很重要，讨论了它的当前状态和支持的语言，并讨论了一些实现细节背后的原因。最后，我们还讨论了开始使用OpenTelemetry方法时的一些注意事项。

OpenTelemetry是什么？

OpenTelemetry是一组标准、库、SDK和代理，提供了完整的应用程序级可观察性。它使用与OpenCensus和OpenTracing相同的基于标准的方法，通过解耦应用程序工具和数据导出来帮助避免厂商锁定。OpenTelemetry庞大的生态系统由以下几部分组成：

• 标准/规范
• API
• SDK具体实现了的API
  • Metrics（指标）
  • Tracing（跟踪）
  • Auto-Instrumentation（自动检测）
  • Exporters（导出器）
• Collector（收集器）

OpenTelemetry生态系统

标准和规范

OpenTelemetry采用了一种基于标准的实现方法。对标准的关注对于OpenTelemetry来说尤其重要，因为它需要追踪跨语言的互操作性。许多语言都带有类型定义，可以在实现中使用，例如用于创建可重用组件的接口。

特定于API语言的类型和接口

每种语言都通过其API实现规范。API包含特定于语言的类型和接口定义，它们是抽象类、类型和接口，由具体的语言实现使用。它们还包含无操作（no-op）实现，以支持本地测试并为单元测试提供工具。API的定义位于每种语言的实现中。正如OpenTelemetry Python客户端所述：

“opentelemetry-api包包括抽象类和无操作实现，它们组成了遵循规范的OpenTelemetry API。”

你可以在OpenTelemetry Javascript客户端中看到类似的定义：

“这个包提供了与OpenTelemetry API交互所需的所有东西，包括所有TypeScript接口、枚举和no-op实现。它既可以在服务器上使用，也可以在浏览器中使用。”

SDK规范实现

SDK是将导出器与API结合在一起的粘合剂。SDK是具体的、可执行的API实现。本节的其余部分将探索每个主要的OpenTelemetry组件：导出器、指标、跟踪、自动检测和收集器。

Exporters（导出器）

导出器使你能够从应用程序中提取数据，并将数据转换为特定的检测协议和供应商。这里的导出器概念与OpenCensus和OpenTracing是相同的。因此，你可以使用OpenTelemetry来测试应用程序，然后配置一个导出器来确定OpenTelemetry数据被发送到哪里。这样可以将工具与任何特定的供应商或协议解耦，避免供应商锁定。

Metrics（指标）

如果你已经使用过OpenCensus，那么你应该非常熟悉指标。将指标（实际指标事件）与输出器组合在一起的基本特性在OpenTelemetry中称为Meter。指标特性是通用的，用于捕获各种指标事件，如下所示：

Meter的使用例子

Tracing（跟踪）

在OpenTelemetry中追踪与OpenTracing非常相似。OpenTelemetry引入了TracerProvider的概念，它可以以单例模式为全局跟踪器实例建模，类似于OpenTracing的全局跟踪器。OpenTelemetry还引入了额外的抽象，比如SpanProcessor，它将导出器连接到OpenTelemetry API调用：

Tracer/exporter配置

Auto-Instrumentation（自动检测）

自动检测是动态检测用于跟踪的特定于语言的库的能力。检测用于跟踪的库需要在所有调用站点中传播跟踪上下文。在遗留项目和大型项目中，修改代码来传播这一点可能非常困难，在node.js这样的语言中更是难上加难，它一直缺乏线程本地存储。自动检测将自动修补公共库（如HTTP客户端/服务器、web框架和数据库客户端）以自动添加跟踪！

Epsagon还将其特定于语言的自动检测框架集成到Python、Ruby、Java、Go和Node.js、PHP和.NET中，这大大减少了检测跟踪所需的时间。

Collector（收集器）

OpenTelemetry最大的新功能之一就是代理的概念。代理是收集指标的独立守护进程。为了支持代理，OpenTelemetry创建了它的提供者无感协议：collector。这就将遥测技术的输出和转换与采集分离开来。OpenTelemetry还提供了一种新的与供应商无关的协议来支持收集器。虽然该协议仍处于起步阶段，但其目标是进一步将可观察性工具与特定供应商分离！

为什么OpenTelemetry？

以下是CNCF发展背后的一些原因。

标准的进化

这些新组件和抽象的一个原因是标准的演进。OpenCensus从谷歌开始，用一个定制为谷歌跟踪实现的跟踪实现来表示它的策略。OpenTracing是OpenCensus的进化，采用基于标准的方法来实现追踪。这两个项目都继承了“导出器”的概念，并将检测与导出脱钩。OpenTelemetry是这两个框架的结合。一旦OpenTelemetry是稳定的，就不需要使用多个框架，但是在它稳定之前，考虑OpenCensus和OpenTracing也是很重要的。

多提供者

OpenTelemetry的核心是将语言工具代码与供应商分离。使用OpenTelemetry方法，应用程序只需要测试一次，而不管提供程序是什么。这允许公司根据他们的需要选择最好的提供者，他们甚至可以只对他们的代码做很小的修改就可以改变提供者！而在OpenTelemetry Collector的情况，不需要修改代码！

更通用的API

OpenTelemetry还发展了许多OpenTracing和OpenCensus API，引入了新的概念和抽象。例如，OpenTracing有一个span“标签”（tag）的概念，这是一种将键/值数据附加到单个span的方法。选择标签的最佳实践并没有改变，但是标签的概念已经被“注释”（annotation）所取代，“注释”是“标签”的一种更通用的形式。OpenTelemetry已经为几个不同的组件引入了更多的通用抽象。

此外，它将以前仅是约定的概念（如OpenTracing语义约定）编码到OpenTelemetry API中。在OpenTracing中，span.kind标签是一种约定，它没有被API强制执行，但在一些跟踪提供程序中具有重要意义（OpenCensus指定了SpanKind）。OpenTelemetry将这个概念从OpenCensus引入到API中，并使SpanKind成为span的属性。下图显示了一个在OpenTelemetry中有一个显式kind的例子：

Span创建时的SpanKind

异步事件

OpenTelemetry通过其Links API将异步事件视为一等公民。在OpenTracing中，有两种方法来建模span之间的因果关系。这种关系是在Tracer.StartSpan()调用的过程中指定的：

• ChildOf：Parent依赖于新span的结果。
• FollowsFrom：Parent不依赖于新的span结果。

它通过Links API显式地建立因果关系，从而消除了这种区别。下面的例子展示了用于创建新span的Golang API，它指定了链接：

Linked的Go例子

支持的语言

OpenTelemetry支持所有主要的编程语言。关于不同项目状态的详细信息可以在OpenTelemetry网站和每种语言的GitHub页面上找到。

OpenTelemetry语言进展

进展很快，所以要经常检查！现在缺失的功能可以在几天或几周内轻松实现。

开始学习OpenTelemetry

由于这仍然是一个年轻的项目，你需要在开始之前执行一些背景研究。这是一个好主意：

• 检查OpenTelemetry语言版本。
• 检查目标语言的特性支持。
• 检查目标语言的导出器。

在此之后，你应该在给定的GitHub仓库中查看所选语言的示例。

总结

OpenTelemetry拥有一站式可观察解决方案所需的所有组件：

• 标准优先
• 特定于语言的SDK
• 指标
• 跟踪
• 收集器
• 自动检测

OpenTelemetry旨在体现指标和追踪，这是可观察性三大支柱中的两大支柱。但是在进行转换之前，请确保它是否支持你想要使用的语言，因为每种语言都处于不同的实现阶段，并且有些特性可能无法在所有语言中使用。在过去的6个月里，OpenTelemetry取得了显著的进步，并且还在继续这样做。如果你正在考虑实现，它为OpenCensus和OpenTracing提供了向后兼容性，减少了开始时的摩擦。