Opentelemetry Architecture
在 Collector 内部设计中，一套数据的流入、处理、流出的过程称为 pipeline。一个 pipeline 有三部分组件组合而成，它们分别是 receiver/ processor/ exporter。
receiver 负责按照对应的协议格式监听接收遥测数据，并把数据转给一个或者多个 processor processor 负责做遥测数据加工处理，如丢弃数据，增加信息，转批处理等，并把数据传递给下一个 processor 或者传递给一个或多个 exporter exporter 负责把数据往下一个接收端发送（一般是遥测后端），exporter 可以定义同时从多个不同的 processor 中获取遥测数据Collector Pipeline
从上面的设计可以看出，Collector 除了提供让遥测数据收集与业务逻辑处理正交的能力，还充当了遥测数据对接遥测后端的适配器。Collector 可以接收 otlp, zipkin, jaeger 等任意格式的数据，然后以 otlp, zipkin, jaeger 等任意格式的数据转发出去。这一切只取决于你需要输入或输出的格式是否有对应的 receiver 和 exporter 实现。 otlp 相关的实现都是在 opentelemetry-collector 仓库中。而 otlp 以外的协议实现，则是可以参考下面代码仓库。
代码仓库：opentelemetry-collector-contrib
各语言监测客户端 API & SDK
Opentelemetry 为每种语言提供了基础的监测客户端 API & SDK 包。这些包一般都是根据 opentelemetry-specification 里面的建议与定义，以及结合语言自身的特点，实现了在客户端采集遥测数据的基本能力。如元数据在服务间、进程间的传递，Trace 添加监测与数据导出，Metrics 指标的创建、使用及数据导出等。以下为各语言监测客户端 API & SDK 包对应的代码仓库表。
语言
仓库地址
C++
opentelemetry-cpp
.NET
opentelemetry-dotnet
Erlang
opentelemetry-erlang-api & opentelemetry-erlang
Golang
opentelemetry-go
Java
opentelemetry-java
javaScript
opentelemetry-js-api & opentelemetry-js
PHP
opentelemetry-php
Python
opentelemetry-python
Ruby
opentelemetry-ruby
Rust
opentelemetry-rust
Swift
opentelemetry-swift
按照 Opentelemetry 项目的规划，2021 年上半年大部分组件完成 Tracing 的支持。以目前的时间点（2021年12月）来看，C++/.NET/Golang/Java/Javascript/Python/Ruby 监测客户端对 Tracing 支持已经进入 Stable 状态。 Erlang/Rust/Swift 监测客户端对 Tracing 支持则是进入了 Beta 测试阶段。
而 Opentelemetry 项目规划对于 Mertics 的支持则晚一些。希望在 2021 年下半年大部分组件能够完成 Metrics 的支持。以目前情况来看，各语言客户端包对于 Metrics 支持还处在 Alpha 测试阶段。 而对于 Logs 的支持，则是计划在 2022 年开始。
Instrumentation & Contrib
如果单纯使用监测客户端 API & SDK 包，许多的操作是需要修改应用代码的。如添加 Tracing 监测点，记录字段信息，元数据在进程/服务间传递的装箱拆箱等。这种方式具有代码侵入性，不易解耦，而且操作成本高，增加用户使用门槛。这个时候就可以利用公共组件的设计模式或语言特性等来降低用户使用门槛。
利用公共组件的设计模式，例如在 Golang 的 Gin 组件，实现了 Middleware 责任链设计模式。我们可以引用 github.com/gin-gonic/gin 库，创建一个 otelgin.Middleware，手动添加到 Middleware 链中，实现 Gin 的快速监测。
利用语言特性的，例如 Java 使用 Java Agent 的能力与 bytebuddy 字节码织入技术，在 Java 应用启动之前找到对应类和方法，修改字节码注入监测，实现对指定类的自动监测。
理论上来说，快速监测依赖于客户端 API & SDK，自动监测则依赖于快速监测。但是实际操作却并没有按理论的来。如 Java 语言利用 Java Agent 与 bytebuddy 技术可以实现对指定开源组件实现全自动监测的，所以就没有单独提供快速监测（在 OpenTracing 里面是有分开的）。
语言
快速监测
自动监测
Python
opentelemetry-python-contrib
opentelemetry-python-contrib
javaScript
opentelemetry-js-contrib
opentelemetry-js-contrib
Ruby
opentelemetry-ruby
opentelemetry-ruby
Java
(x)
opentelemetry-java-instrumentation
Golang
opentelemetry-go-contrib
(x)
.NET
opentelemetry-dotnet-contrib
opentelemetry-dotnet-instrumentation
Erlang
opentelemetry-erlang-contrib
Rust
opentelemetry-rust
Swift
opentelemetry-swift
总结
Opentelemetry 的使命是实现收集高质量、大范围、便携的遥测数据，让有效的可观测性设施成为可能。它本身并不提供完整的可观测性解决方案，而是提供了统一的遥测数据采集方案。而如果是需要搭建一套完整的可观测性设施，还需要搭配相应的监测后端做数据持久化与数据查询，如 Tracing 后端 zipkin/jaeger/tempo/，metrics 后端 prometheus，logs 后端 loki 等。