基于OpenTelemetry实现可观测性-Part 6 生态

Posted 2023-04-05 apl359

泽注：这是一个系列，共分成6部分，这是第6部分。翻译自：https://trstringer.com/otel-part6-ecosystem/

之前的五篇博客涵盖了如何使用OpenTelemetry观测你的应用程序的技术细节。我认为用OTel生态系统的一些信息来结束这个博文系列会产生很大的价值。OpenTelemetry社区发生了很多事情，那些刚接触它的人可能会有点不知所措，或者对在哪里找到某些东西感到困惑。

如前所述，OpenTelemetry是一个CNCF项目。但是，它的表现如何呢？以PR、Issue和提交数来衡量，OpenTelemetry是CNCF项目中第二活跃的，仅次于Kubernetes：

image.png

Image and data source (twitter)^[1]

这是一个非常激动人心的时刻，可以深入OpenTelemetry的世界。希望现在已经很明显了，但我相信OpenTelemetry会继续保持，并将在云原生生态系统中发挥重要作用。

项目网站

OpenTelemetry的起来是它的项目网站： opentelemetry.io^[2]。在这里，你可以找到大量的信息和好的生态系统的索引。在这里，你还可以找到非常棒的入门教程，从中熟悉OTel并在你的软件中实现它。

OpenTelemetry网站的一个值得关注的部分是项目博客^[3]。在这里你会发现大量的更新和公告。

一般来说，如果你是OpenTelemetry的新手，我强烈建议你花一些时间在项目网站上学习。

社区

如果说这个系列博文强调了一件事，那就是OTel有一个庞大的功能集。而这些功能往往伴随着一定程度的复杂性。在某些时候，你可能需要社区的帮助。我发现与社区成员（包括维护者！）聊天的最好方式是通过CNCF Slack工作区。OpenTelemetry有几个频道，你可能感兴趣。主要的一个是#opentelemetry，这是一般的讨论。不过你也有可能想参与更多具体的对话。这里有一些其他的OTel频道：

• • #otel-collector：关于OpenTelemetry Collector的一切；

• • #otel-go - OpenTelemetry Go (API, SDK, 实现)

• • #otel-python - OpenTelemetry Python (API, SDK, 实现)

还有一些，在 Slack 中搜索“#otel”以查看其他 OpenTelemetry 频道。

这可能是下一节的一部分，但在这里值得一提。 社区的Git仓库^[4] 有很多重要信息，例如：治理、感兴趣的领域、会议和日历等等。如果您正在考虑加入 OTel，这是一个很好的起点。

代码仓库列表

我必须承认，当我开始使用 OpenTelemetry 时，我最困惑的事情之一是 GitHub仓库^[5] 的组织方式。

OpenTelemetry的主要组件（不是语言或者特定的collector）可以在这些仓库中找到：

• • open-telemetry/opentelemetry-specification^[6] - The OTel spec (procotol, metrics, traces, logs, baggage, and many other specifications for root OTel), schema, and semantic conventions

• • open-telemetry/oteps^[7] - Enhancement proposals for the project

• • open-telemetry/opentelemetry-proto^[8] - Protobuf definitions for OTLP

OTel Collector 仓库:

• • open-telemetry/opentelemetry-collector^[9] - Core collector code, 包括 ocb^[10] 工具

• • open-telemetry/opentelemetry-collector-contrib^[11] - Contrib receivers, extensions, processors, and exporters for the collector

• • open-telemetry/opentelemetry-collector-releases^[12] - Releases for core and contrib distros are not in the above two repos, but they are here including the manifests and Dockerfiles for the release distros

• • open-telemetry/opentelemetry-operator^[13] - Kubernetes operator to handle the collector, including collector sidecar injection for observed application pods

OTel的一个重要部分是特定语言的探测实现。这里有一个案例，解释了它们在项目中是如何组织的：

• • open-telemetry/opentelemetry-go^[14] - Go API and SDK

• • open-telemetry/opentelemetry-go-contrib^[15] - Extensions for OTel Go, including instrumentation^[16] and propagators^[17]

• • open-telemetry/opentelemetry-python^[18] - Python API and SDK

• • open-telemetry/opentelemetry-python-contrib^[19] - Extensions for OTel Python

这是语言实现的一般模式，但它们可以有所不同。例如，Java有open-telemetry/opentelemetry-java，但也有open-telemetry/opentelemetry-java-contrib用于扩展，但有open-telemetry/opentelemetry-java-instrumentation用于自动探测实现的单独 repo。

注册表

我认为应该注意的生态系统的最后一部分是OpenTelemetry Registry^[20]。由于该项目有大量的实现和产品，这是一个搜索任何你想要实现需求的好地方。

总结

OpenTelemetry是一个伟大的项目，它提供了一种在我们开发的软件中实现高水平的可观测性的方法。通过OTel，我们能够有最大限度的洞察力，并回答线上问题，而不需要做任何代码修改。我强烈建议你深入OpenTelemetry的奇妙世界！一旦你这样做了，你就永远不会想离开它了。

引用链接

[1] Image and data source (twitter): https://twitter.com/hab_mic/status/1557012045677092866?s=20&t=-Chw2r-CBO6W2gVTRlZgyw
[2] opentelemetry.io: https://opentelemetry.io/
[3] 项目博客: https://opentelemetry.io/blog/
[4] 社区的Git仓库: https://github.com/open-telemetry/community
[5] GitHub仓库: https://github.com/open-telemetry
[6] open-telemetry/opentelemetry-specification: https://github.com/open-telemetry/opentelemetry-specification
[7] open-telemetry/oteps: https://github.com/open-telemetry/oteps
[8] open-telemetry/opentelemetry-proto: https://github.com/open-telemetry/opentelemetry-proto
[9] open-telemetry/opentelemetry-collector: https://github.com/open-telemetry/opentelemetry-collector
[10] ocb: https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder
[11] open-telemetry/opentelemetry-collector-contrib: https://github.com/open-telemetry/opentelemetry-collector-contrib
[12] open-telemetry/opentelemetry-collector-releases: https://github.com/open-telemetry/opentelemetry-collector-releases
[13] open-telemetry/opentelemetry-operator: https://github.com/open-telemetry/opentelemetry-operator
[14] open-telemetry/opentelemetry-go: https://github.com/open-telemetry/opentelemetry-go
[15] open-telemetry/opentelemetry-go-contrib: https://github.com/open-telemetry/opentelemetry-go-contrib
[16] instrumentation: https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/instrumentation
[17] propagators: https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/propagators
[18] open-telemetry/opentelemetry-python: https://github.com/open-telemetry/opentelemetry-python
[19] open-telemetry/opentelemetry-python-contrib: https://github.com/open-telemetry/opentelemetry-python-contrib
[20] OpenTelemetry Registry: https://opentelemetry.io/registry/

OpenTelemetry 简析

• 组件闭环的信息

• 组件间或系统间流动的信息

第一种形态通常可通过 logs 或 metrics 表征，第二种形态就需要 trace 表征，在流动的信息中增加标记。

对于 logs 和 metrics 的区别，可通过它们的操作方法进行理解。

再进一步抽象，可观测性涉及到如下问题：

• 观测数据的数据模型

• 观测数据的采集

• 观测数据的处理

• 观测数据的导出

• 观测数据的使用

• etc.

上述即是 OpenTelemetry 面对的问题域及具体的问题，且将具体的问题限定在：

• 观测数据的数据模型

• 观测数据的采集

• 观测数据的处理

• 观测数据的导出

[](()OpenTelemetry 的解决方案是什么？

---

OpenTelemetry 通过 Spec 规范了观测数据的数据模型以及采集、处理、导出方法，包括 trace、metrics、logs (未来不排除会有新的类型)，参见 [opentelemetry-specification](()。

同时为了方便使用，通过 protobuf 来描述，参见[opentelemetry-proto](()。

基于 Spec，OpenTelemetry 面向观测数据的生成和处理，做了如下的努力：

• 为了方便开发者使用，提供了语言相关的 SDK，如 [opentelemetry-go](()、[opentelemetry-java](()、[opentelemetry-js](() 等，所有支持的开发语言可参见 [官方文档](()

• 为了方便可观测数据的采集、处理、导出，提供了通过配置管理的 Collector 服务，如对接开源项目的 [opentelemetry-collector](()、对接第三方 vendor 的 [opentelemetry-collector-contrib](()

通过下图可直观理解 OpenTelemetry 的组件和工作流：

[](()OpenTelemetry 的历史是什么？

---

从 [A brief history of OpenTelemetry (So Far)](() 可简单了解到，OpenTelemetry 是由两个开源项目合并组成的：

• [OpenCensus](()

• 面向 trace 和 metrics 进行数据模型标准化，并提供采集、处理、导出的工具

• [OpenTracing](()

• 面向 trace 进行数据模型标准化，并提供采集、处理、导出的工具

2019 年 5 月，两个开源项目合并，官方宣布开源 OpenTelemetry 项目。

2021.02，trace spec 达到 1.0 版本，根据官方的成熟度模型 (link，目前 trace 的 s 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 pec 已经达到 stable 级别，metrics 达到了 beta 级别，logs 当前还处在 alpha 级别：

[](()OpenTelemetry 的前景如何？

---

自 OpenTelemetry 推出以来，有越来越多的厂商开始关注和贡献。

从 [opentelemetry-collector-contrib](() 可看出来，厂商的关注重点在于 exporter 部分，将观测数据便利导入到自身的服务中，其中已经包含阿里云自身的 [SLS 产品](()：

对于 receiver 和 processor 环节，相信厂商也会逐步投入更多的精力，如：

• 通过 receiver 和 exporter 的配合，形成观测数据的处理 workflow

• 通过 processor，在观测数据存储前进行规范化处理

对于多云场景，OpenTelemetry 定义的观测数据模型、采集/处理/导出 标准，将有利于用户通过一套可观测性标准对接多种云厂商，避免 vendor 锁定。

即使是面向单一的云 (如云厂商内部的服务)，也不可避免会考虑未来进行开源、与外部共建等，使用社区的可观测性标准可以降低开源成本。同时，可观测性的理念、标准、技术在不断迭代，通过跟进社区，可以更好使用到社区带来的技术红利和影响力。

因此，无论是面对多云场景还是单一的云厂商，采用业界的可观测性标准都是很有必要。

[](()OpenTelemetry 如何使用？

---

[](()核心概念

OpenTelemetry 中的概念比较多，这里列举些常见的概念，方便进行理解：

• 观测数据相关

• Signal

• 观测数据类型，如 trace、metrics、logs

• Instrument

• 可认为是某种 Signal 的实例

• OpenTelemetry 自身项目相关

• API

• OpenTelemetry Spec 的形式化描述，如 [opentelemetry-proto](()

• SDK

• 面向不同开发语言的 API 实现

• Contrib Packages

• 与具体的开源项目或 vendor 产品相关的实现

• 使用的组件相关

• Components

• Receivers

• 接收观测数据的组件

• Processors

• 处理接收到的观测数据的组件

• Exporters

• 将观测数据导出的组件，如导出到开源项目 Prometheus 或云厂商服务中

• Extensions

• 不参与观测数据的处理，辅助相关处理组件的运行，如健康检测、服务发现等

• Services

• 表征配置的哪些组件需要运行，如 receivers / processors / exporters / extentions

• Collector

• 可认为是 receivers / processors / exporters / extentions / services 组成的整体

• Controller

• 用于开发者开发的应用中，作用可等同于 receivers / processors / exporters 组成的整体

[](()golang demo

笔者写了一个 golang demo，用来演示：

• APP 中如何生成 trace / metrics 数据

• APP 中使用 stdout controller 来采集、处理、打印 trace / metrics 数据

• APP 中通过 otlp controller 采集 trace / metrics 数据，并导出到外部运行的 collector 中

• 本地独立运行一个 collector 服务，接收 otlp controller 推送的 trace / metrics 数据，并将其导出到本地文件和阿里云 SLS 中

demo 参见：[https://github.com/flyer103/otel-demo](()

具体的使用方法参见 demo 的 README.md，下述简单描述下思路。

cmd/app/server.go 文件描述了 OpenTelemetry 的使用逻辑，分成两部分：

1. 初始化并运行全局的 controller，用来在 APP 内部 receive / process / export 观测数据，或将 APP 内的观测数据推送到外部

2. APP 内按照业务需求生成 metrics 和 trace