Opentelemetry 调研实践二（OpenTelemetry 架构及名词介绍）

上文^[1]简单说了下可观测性，然后引出了主角: opentelemetry。

可观测性一个很重要的领域Trace有两个业界标杆: 一个是OpenTracing^[2]，另一个OpenCensus^[3]，OpenTracing 其实是一个规范，jeager 就是基于 opentracing 实现的开源工具，而 OpenCensus 则是由 google 开源的度量工具，简单来说，这两者在可观测性领域功能高度重合，因此，在 CNCF 主导下进行了合并形成 opentelemetry 项目，OpenTracing 跟 penCensus 共同推进 opentelemetry，两者的官网也赫赫表达基本不再维护，同时 opentelemetry 也致力于 trace、logging、metrics 间的关联性。

OpenTelemetry 核心工作

• 1.规范的制定和协议的统一，规范包含数据传输、API 的规范，协议的统一包含：HTTP W3C 的标准支持及 GRPC 等框架的协议标准
• 2.多语言 SDK 的实现和集成，用户可以使用 SDK 进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack 等）进行集成支持
• 3.数据收集系统的实现，当前是基于 OpenCensus Service 的收集系统，包括 Agent 和 Collector。

由此可见，OpenTelemetry 的自身定位很明确：数据采集和标准规范的统一，对于数据如何去使用、存储、展示、告警，官方是不涉及的。

OpenTelemetry 状态

OpenTelemetry 要解决的是对可观测性的大一统，它提供了一组 API 和 SDK 来标准化遥测数据的采集和传输，opentelemetry 并不想对所有的组件都进行重写，而是最大程度复用目前业界在各大领域常用工具，通过提供了一个安全，厂商中立的能用协议、组件，这样就可以按照需要形成 pipeline 将数据发往不同的后端。

由于 opentelemetry 提出时间并不长，大家可以从status^[4]中可以看到最新的状态，可以看到，目前只有 Tracing 实现了 1.0 的 release，而 Metrics 处于feature-freeze^[5]，这个状态说的是 metrics 目前暂不接受在 metrics 中添加新的功能，以便技术委员会优先实现其它功能，还未达到 stable 状态，而在 Logging 则还处于草案阶段，opentelemetry 官方的解释是日志相对存在体量大，延时高的问题，相对棘手且优先级对比另两者不高。

tracing 已经在 2021 上半年实现了 stable,目前官方给出的时间线是在 2021 下半年实现 metrics 的 stable，在 2022 实现 logging 的 stable。

为什么 tracing 是首先 stable 的，作者个人感觉可能是 tracing 目前在业界普及度还不够吧，而像 metrics 方面，prometheus 早已成了业务标准。

OpenTelemetry 架构

这里作者还要重点说明的是，就算是 Service Mesh 中对于链路追踪也普遍有一个问题: 就是无论你在数据平面如何做流量劫持，如何透传信息，以及如何生成或者继承 Span，入口流量和出口流量之间的链路都存在无法串联的问题， 这个问题要解决还是需要服务来埋点透传，将链路信息透传到下一次请求当中去，这个问题是无法避免的，而 OpenTelemetry 的后续推行，可以解决这方面的标准化问题。

来看一张图:

注: 由于 logging 还处于草案状态，这里没有描述出来。

opentelemetry 也是个插件式的架构，针对不同的开发语言会有相应的 Client 组件，叫Instrumenttation，也就是在代码中埋点调用的 api/sdk 采集 telemetry 数据。

将获取到的数据 pull/push 到上图中定义好的pipeline中,这部分是可高度定制的, opentelemetry 提供统一的Specification^[6]。

pipeline就是Collection的实现，大概分为 3 部分，这里简单介绍一下，后期在详解 collection 的配置文件时再进行展开:

• receivers(接收者): 定义从 client 端的数据要以何种数据模型进行接收, 支持很多种数据模型.
• processors: 将 receivers 的数据进行某些处理，比如批量、性能分析等.
• exporters: 将 processors 后的数据导出到特定的后端，比如 metrics 数据存储到 prometheus 中.

整个流程是 pipeline 式的,可以根据实际情况自定义 pipeline,所以说 collector 定制性很高。

这里要说明的是 receivers、processors、exporters 有官方的定义opentelemetry-collector^[7]

但是也有很多开源产品基于 opentelemetry-collector 提供相应的实现,详细列表参考opentelemetry-collector-contrib^[8]

总结一下，opentelemetry 按功能分层来说,可以分为：采集器（Instrument）、发送器（TransPort）、收集器（Collector）、存储（Srotage）、展示（API&UI）,这跟其它 APM 系统是类似的，只是 opentelemetry 在很多组件上选择了利用而不是重新造轮子。

在 opentelemetry 里面的名词也是非常多的，有必要把一些常用的名词给大家解释一下。

建议大家多多阅读官方文档，也可参考[OpenTelemetry 规范阅读](https://jckling.github.io/2021/04/02/Jaeger/OpenTelemetry 规范阅读/ "OpenTelemetry 规范阅读")，里面详细介绍了各个名词的含义，对大家理解有帮助。

OpenTelemetry 核心概念

以下名词引用官方文档components^[9]的翻译。

Proto

语言无关的接口类型。描述很多下文组件的定义。

####Client

其实就是 client, 应用调用 OpenTelemetry API 的 client, 语言相关的代码封装库，引入 trace、metrics、log 等。

API/SDK

API 包由用于检测的横切公共接口组成，导入到第三方库和应用程序代码的 OpenTelemetry 客户端的任何部分都被认为是 API 的一部分。

而 SDK 是 API 的具体实现，这部分是语言相关的。

Specification

Specification 则是定义了 API/SDK 及数据模型，所有包含第三方实现的都需要遵循 spec 定义的规范。

Semantic Conventions

OpenTelemetry 项目保证所有的 instrumentation(不论任何语言)都包含相同的语义信息。

Resource

resource 附加于某个 process 产生的所有 trace 的键值对，在初始化阶段指定并传递到 collector 中。

Baggage

为添加在 metrics、log、traces 中的注解信息，键值对需要唯一，无法更改。

Propagators

传播器，比如在多进程的调用中，开启传播器用于跨服务传播 spanContext。

Attributes

其实就是 tag, 可以给 span 添加 metadata 数据,SetAttributes属性可以多次添加，不存在就添加，存在就覆盖。

Events

类似于日志, 比如在 trace 中嵌入请求体跟响应体。

Collector

虽然 Collector 翻译过来叫接收，但它负责遥测数据源的接收、处理和导出三部分，提供了与供应商无关的实现。

collector 是个实体组件，有两个部署方案，可以 ds 进行部署，各个 host 负责该 host 上的遥测数据。

或者以 deployment 的方式部署，接收所有遥测数据。

其中，Metrics、Logging、Trace、Baggage 叫Signal,以上的对象中除了Collector,其它几个由于没有具体部署对象，名词一多理解起来还是比较费劲，需要多翻官方文档。

这里重点介绍 Collector，在介绍 Collector 前，先来介绍一个协议。

OpenTelemetry 协议-OTLP

OTLP(OpenTelemetry Protocol)^[10]是一种协议，该此协议用于将应用产生的遥感数据发送到 OpenTelemetry Collector。

otlp 是 opentelemetry 中比较核心的存在，在遥测数据及 Collector 之间制定了包括编码(encoding)、传输(transport)、传递(delivery)等协议。

目前 OTLP 协议在数据源的状态也是不一样的。

• Tracing: Stable
• Metrics: Stable
• Logs: Beta

otlp 也对 http、grpc 进行了较好的开箱即用的封装。

另外，OTEP(OpenTelemetry Enhancement Proposal)是加强版的 otlp, 目前处于不稳定状态，这里不展开。

参考文章:

• https://codingnote.cc/p/246692^[11]
• https://opentelemetry.io/registry^[12]
• https://opentelemetry.io/docs/concepts/components^[13]
• https://signoz.io/blog/opentelemetry-kubernetes^[14]
• https://www.infoq.cn/article/pky4szfhbvifxrcriqcr^[15]
• https://github.com/open-telemetry/opentelemetry-collector^[16]
• https://github.com/open-telemetry/opentelemetry-collector-contrib^[17]
• https://tech.ipalfish.com/blog/2020/12/29/design-dimensions-of-tracing-systems^[18]
• https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/protocol^[19]
• https://jckling.github.io/2021/04/02/Jaeger/OpenTelemetry%20%E8%A7%84%E8%8C%83%E9%98%85%E8%AF%BB^[20]

引用链接

你可能还喜欢

点击下方图片即可阅读

云原生是一种信仰 🤘

关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！