基于OpenTelemetry进行全链路追踪

Luga Lee

发布于 2023-04-28 15:43:27

3.1K1

发布于 2023-04-28 15:43:27

Hello folks，我是 Luga，今天我们来分享一下与云原生体系有关的话题- 云原生可观测性-OpenTelemetry。作为一个云原生“核心”标准，OpenTelemetry在观测分布式微服务应用程序和云基础设施的可见性和控制自动化层面具有举足轻重的意义。

— 01 —

Observability-可观测性鸟瞰

正如之前文章所述，可观测性是根据对系统产生的外部数据（例如日志、指标和跟踪）的了解来获取系统内部发生的事情的能力。

可观测性通常通过遥测数据来辅助，遥测数据可以通过 Dynatrace 以及 OpenTelemetry 等开源项目提供。OpenTelemetry 是一个云原生计算基金会 (CNCF)沙盒项目，其目标是提供一组统一的供应商不可知库/API、SDK 和其他工具。它的主要贡献者之一是 Dynatrace。

基于 OpenTelemetry，IT 团队可以检测他们的应用程序并生成、收集和导出遥测数据，以分析和了解软件架构性能和系统行为。

正如 Kubernetes 已成为容器编排的事实标准一样，OpenTelemetry 现在是为云原生应用程序添加可观测性的事实标准。这意味着公司无需花费宝贵的时间开发用于收集应用程序遥测数据的机制，而是可以专注于他们的主要产品。

— 02 —

什么是 OpenTelemetry？

OpenTelemetry（也称为 OTel）是一个开源可观察性框架，由一系列工具、API 和 SDK 组成。Otel 使 IT 团队能够检测、生成、收集和导出遥测数据以进行分析并了解软件性能和行为。

作为一个CNCF项目，OpenTelemetry 定义了语言中立的规范，并提供了API、SDK的集合，用于以与供应商无关的方式处理日志、度量和跟踪等可观察性数据。该项目由两个竞争项目——OpenTracing 和 OpenCensus 的融合而成，并得到了来自谷歌、微软、亚马逊的主要云提供商以及可观察性领域几乎所有供应商的支持——Splunk、Elastic、Datadog、LightStep、DynaTrace、NewRelic、Logzio、HoneyComb 等。让我们探索在现有和未来的绿地项目中采用 OpenTelemetry 的好处。

1、OpenTelemetry 规范的语言中立性允许以不同语言实现‍

目前，截至本文撰写时，OpenTelemetry 的 SIG- 特殊兴趣组提供了一些最广泛使用的通用语言的实现：C++，。Net，Java，Javascript，Python，Go，Rust，Erlang，Ruby，PHP，Swift。这些是一组专门的贡献者，专注于单一语言的实现。如果有一个软件项目使用目前不受支持的语言，那么将来可能会得到支持。所有这些都意味着在实现软件组件时具有更大的灵活性；无论语言选择如何，仪器都是一样的。

2、OpenTelemetry可扩展性架构

OpenTelemetry 的可扩展架构意味着库/插件作者可以使用 API 仪器化他们的代码，当这些工件在实现 OpenTelemetry SDK 的服务或应用程序中使用时，服务代码和第三方库的性能都有可见性。微软的分布式应用程序运行时库就是一个例子。有Spring、Express 等流行框架的插件。

3、OpenTelemetry 防止供应商锁定

OpenTelemetry Collector 允许接收、处理和导出遥测数据，支持不同的开源有-Jaeger、Prometheus、Fluent Bit、W3C TraceContext 格式、Zipkin 的 B3 标头等。更重要的是，随着出口商对不同遥测后端的实施，供应商之间的切换变得轻而易举。例如，人们可以将他们的跟踪数据传输到 NewRelic、Elastic、Zipkin 的部署实例等......这都是收集器上的简单配置更改。将其视为仪器作为一种抽象形式，其中遥测数据的目标后端从应用程序/服务中抽象出来。

— 03 —

OpenTelemetry 参考架构‍

OpenTelemetry 架构围绕几个关键组件展开，其中一些组件可以灵活实现。主要组成部分包括：

1、API 和 SDK

OpenTelemetry SDK 是开发人员用来使用指标、跟踪和日志检测其应用程序的库。而 OpenTelemetry API 定义了应用程序如何相互通信并用于检测应用程序或服务。它们通常可供开发人员在流行的编程语言（例如，Ruby、Java、Python）中使用。因为它们是 OpenTelemetry 标准的一部分，所以它们可以与任何 OpenTelemetry 兼容的后端系统一起使用，从而无需在未来重新检测。

SDK 也是特定于语言的，提供 API 和导出器之间的桥梁。它可以对跟踪和聚合指标进行采样。

2、采集器

OpenTelemetry Collector 是一个可选的中间代理，基于其，可以运行它来接收、处理和导出遥测数据。应用程序通过 OTLP 将遥测数据发送到 OTel 收集器，OTel 收集器在导出到各种可观察性供应商之前执行中间处理，例如批处理或速率限制。

需要注意的是：虽然拥有这个中间代理可能会有所帮助，但它确实会为您的堆栈增加一层额外的基础设施和复杂性。

Collector 的工作基本上围绕处理、过滤、聚合和批量遥测进行，为开发人员提供更大的灵活性来接收、整形和发送数据到多个后端。目前适用于如下两种主要部署模型：

作为应用程序内或与应用程序位于同一主机中的代理，充当主机的数据源（默认情况下，OpenTelemetry 假定本地收集器可用）
作为接收、导出和处理遥测数据的数据管道网关

Collector 由三个组件组成：接收器、处理器和导出器，具体可参考如下所示：

接收器

例如，Jaeger、Prometheus 等，负责通过侦听收集器上特定端口上的调用来推送或拉取应用程序的信号。它们适用于 gRPC 和 HTTP 协议。可以在 GitHub 上找到特定场景或框架的完整接收器列表。

处理器

处理器位于接收器和输出器之间；它们使我们能够在数据通过导出器到达后端之前通过过滤、格式化和丰富数据来塑造数据。常见用例包括数据清理以删除敏感或私人信息、从跨度中导出指标或决定将哪些信号保存到后端。

通常，有许多可用的受支持处理器供使用，当然，也可以开发自己的处理器。它们按顺序工作，因此配置顺序很重要。尽管处理器不是必需的，但可能会根据数据源推荐一些处理器。

导出器

导出器可以将数据推送或拉取到一个或多个配置的后端或目的地（例如，Kafka、OTLP）。其工作方式根据需要将数据转换为不同的格式并将其发送到定义的端点。导出器在检测和后端配置之间创建了一个分离层，因此用户可以在不重新检测代码的情况下切换后端。它支持 HTTP 或 gRPC 协议。流行的导出器包括 Jaeger、Prometheus 和 Zipkin，以及大量其他选项。

3、开放遥测协议

OpenTelemetry 协议 (OTLP) 是 OpenTelemetry 成功的原因之一。它是一种不可知论协议规范，定义了数据编码和用于发送跟踪、指标和日志的传输协议。它可以将数据从 SDK 发送到收集器，然后从收集器发送到选定的后端。使用 Collector 元素，我们可以通过配置适当的接收器从第三方框架中抽象出来。

目前，OTLP 使用协议缓冲区架构 (protobuf)，并支持 gRPC 和 HTTP1.1（JSON over HTTP）传输。