介绍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 提供了向后兼容性，减少了开始时的摩擦。

本文分享自微信公众号 - CNCF（lf_cncf），作者：CNCF

原文出处及转载信息见文内详细说明，如有侵权，请联系 yunjia_community@tencent.com 删除。

原始发表时间：2020-05-12

本文参与腾讯云自媒体分享计划，欢迎正在阅读的你也加入，一起分享。
https://cloud.tencent.com/developer/article/1631033