Z.S.K.'s Records

Opentelemetry调研实践二(opentelemetry架构及名词介绍)

发表于 | 分类于

历史文章:

可观测性到底在说什么

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

可观测性一个很重要的领域Trace有两个业界标杆: 一个是OpenTracing，另一个OpenCensus，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中可以看到最新的状态，可以看到，目前只有Tracing实现了1.0的release，而Metrics处于feature-freeze，这个状态说的是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

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

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

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

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

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

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

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

建议大家多多阅读官方文档，也可参考OpenTelemetry 规范阅读，里面详细介绍了各个名词的含义，对大家理解有帮助

OpenTelemetry核心概念

以下名词引用官方文档components的翻译

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)是一种协议，该此协议用于将应用产生的遥感数据发送到 OpenTelemetry Collector.

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

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

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

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

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

参考文章:

转载请注明原作者: 周淑科(https://izsk.me)

wechat
Scan Me To Read on Phone
I know you won't do this,but what if you did?