使用 OpenTelemetry 构建可观测性 06 - 生态系统

核心摘要

OpenTelemetry 不只是 API、SDK 和 Collector，也是一套由官网、社区、规范、语言实现和组件注册表组成的生态系统。
新手了解 OTel，首选入口是项目官网、项目博客和 CNCF Slack 工作空间。
查规范和协议，重点看 opentelemetry-specification、oteps 和 opentelemetry-proto。
使用 Collector 时，需要区分核心仓库、贡献仓库、发行版仓库和 Kubernetes Operator。
选择语言 SDK、扩展组件或第三方集成时，OpenTelemetry Registry 是更适合检索的入口。

过去的五篇文章讨论了如何使用 OpenTelemetry 来构建可观测性的技术细节。本系列结尾再介绍 OTel 生态系统，是为了回答一个更实际的问题：当你想学习、接入、排查或参与 OpenTelemetry 时，应该先去哪儿找可靠信息。

OpenTelemetry 的发展非常迅速。刚接触它的人经常会困惑：官网、规范仓库、Collector 仓库、语言 SDK、贡献组件、社区频道和注册表之间是什么关系？如果先搞清楚这些入口，后续学习和排障会顺很多。

OpenTelemetry 生态系统是什么

OpenTelemetry 是一个 CNCF 项目。这里的“生态系统”不是单指某个代码仓库，而是围绕 OTel 规范、协议、SDK、Collector、语言实现、社区治理、扩展组件和产品集成形成的一组协作入口。

对使用者来说，可以把它分成四类：

入口	适合解决的问题
项目官网与博客	学习概念、阅读指南、关注公告和更新
CNCF Slack 与社区仓库	提问、参与讨论、了解治理和会议节奏
GitHub 组织下的核心仓库	查规范、协议、Collector、Operator、语言 SDK
OpenTelemetry Registry	查找可用的实现、组件、扩展和产品集成

OpenTelemetry 是一个 CNCF 项目。但是，在 CNCF 项目中 OpenTelemetry 的表现如何？以拉取请求、问题和提交代码的数量来衡量，OpenTelemetry 是第二活跃的 CNCF 项目，仅次于 Kubernetes：

OpenTelemetry

数据源(X Corp)

这说明 OpenTelemetry 已经不是一个边缘项目，而是云原生可观测性领域非常活跃的基础设施项目。对企业来说，学习 OTel 的重点不只是“怎么埋点”，还包括“如何跟上规范、社区和组件演进”。

项目官网

要了解和学习使用 OpenTelemetry，首推项目官网：opentelemetry.io。那里有丰富的信息和指南，可以帮助你快速入门，并在软件中应用 OpenTelemetry。

OpenTelemetry 的项目博客也是值得关注的部分。在那里你会找到很多更新和公告。

通常来说，如果你对 OpenTelemetry 还不熟悉，我强烈建议你花些时间浏览一下项目官网。

可引用地说：OpenTelemetry 官网适合解决“我该怎么开始”的问题，项目博客适合解决“最近社区发生了什么变化”的问题。

社区

OTel 拥有众多的功能集。而随着这些功能的增加，通常也伴随着一定程度的复杂性。在某些时候，你可能需要社区的帮助。

我发现与社区成员（包括维护者！）聊天的最佳方式是通过 CNCF Slack 工作空间。 OpenTelemetry 最主要的频道是 #opentelemetry ，这是一般性讨论。也有一些特定话题或语言版本的频道：

#otel-collector - 所有的有关 OpenTelemetry Collector
#otel-go - OpenTelemetry Go （API， SDK， implementation）
#otel-python - OpenTelemetry Python （API， SDK， implementation）

还有更多！在 Slack 中搜索关键字 ‘#otel’ 看看其他 OpenTelemetry 频道。

在 OpenTelemetry 的社区频道中，你可以找到很多有价值的信息，比如项目的治理、感兴趣的领域、会议和项目排期时间表等等。如果你有兴趣参与 OpenTelemetry 项目，这个社区仓库是一个很好的起点，帮助你更好地了解和参与进来。

术语上可以这样理解：CNCF Slack 更像“实时讨论现场”，社区仓库更像“治理和协作索引”。前者适合问问题，后者适合理解项目如何运转。

项目仓库

我不得不承认，当我开始使用 OpenTelemetry 时，对我来说更令人困惑的事情之一是GitHub项目仓库的组织方式。 OpenTelemetry的主要组件（不是特定于语言或收集器）可以在以下项目仓库中找到：

open-telemetry/opentelemetry-specification - OTel 规范（procotol, metrics, traces, logs, baggage, and many other specifications for root OTel）、架构和语义约定
open-telemetry/oteps - 项目改进提案的仓库
open-telemetry/opentelemetry-proto - OTLP（OpenTelemetry Protocol）的 Protobuf 定义。

OTel 收集器项目仓库包括：

open-telemetry/opentelemetry-collector - 核心收集器代码，包括用于自定义收集器发行版构建的 OCB 工具
open-telemetry/opentelemetry-collector-contrib -贡献版 - 收集器的接收器、扩展、处理器和导出器
open-telemetry/opentelemetry-collector-releases - 用于发布核心和贡献发行版的仓库，包括发行版的清单和 Dockerfiles
open-telemetry/opentelemetry-operator - 用于处理收集器的 Kubernetes operator，包括 sidecar 容器注入到应用程序 Pod 中

此外，针对特定编程语言的埋点库是 OpenTelemetry 的一个重要组成部分。以下是一些项目仓库：

open-telemetry/opentelemetry-go - Go API 和 SDK
open-telemetry/opentelemetry-go-contrib - 针对OTel Go的扩展，包括埋点和传播器。
open-telemetry/opentelemetry-python - Python API 和 SDK
open-telemetry/opentelemetry-python-contrib - OTel Python 的扩展

有些编程语言的仓库可能不同。例如，Java 语言实现的主要仓库是 open-telemetry/opentelemetry-java ， open-telemetry/opentelemetry-java-contrib 用于扩展，对于埋点有一个单独的仓库 open-telemetry/opentelemetry-java-instrumentation。

OpenTelemetry Registry

OpenTelemetry 生态系统中的最后一个重要组成部分是 OpenTelemetry 注册表。由于项目中存在着各种实现和产品组合，用户可以在一个地方浏览和搜索可用的实现和产品。他们可以根据自己的需求和偏好，选择最适合他们的解决方案。

Registry 的价值在于检索。你不必在多个仓库和文档之间反复跳转，而是可以围绕语言、组件类型、接收器、导出器、扩展和产品集成来查找可用实现。

FAQ

新手学习 OpenTelemetry 应该先看哪里？

先看 opentelemetry.io 的入门指南和概念文档，再根据你的语言栈查看对应 SDK 仓库。如果需要了解最近变化，再看项目博客和社区讨论。

OpenTelemetry 的规范、协议和实现分别在哪里？

规范主要在 opentelemetry-specification，OTLP 的 Protobuf 定义在 opentelemetry-proto，语言 API 和 SDK 分散在 Go、Python、Java 等语言仓库中。Collector 相关代码则主要在 Collector 核心仓库和 contrib 仓库。