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

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