喝!这个世界,又多了一点抽象!

2,052 阅读5分钟

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

如果你常年在处理一些日志、监控方面的东西,一定会在一定程度上听过OpenTracing,像 Zipkin、Jaeger、SkyWalking都对其有很好的支持。

但是可惜,OpenTracing已经成为过去式了,现在的APM世界,由一种叫做OpenTelemetry的规范所统治。

那是因为,作为一个标准,OpenTracing遇到了对手。

1. 小历史

很多同学已经开始喊了,我的OpenTracing还没学热乎呢,现在直接被冻结了。这要怪google。

OpenTracing诞生于2016年11月,CNCF接受了它,成为自己基金会的第三个项目。但是google并不认为这个东西是标准,所以推出了自己的OpenCensus规范。

CNCF是什么呢?cn并不是中国的意思,它的全称是Cloud Native Computing Foundation,是Linux基金会旗下的基金会,可以理解为一个非盈利组织。当年google就把自己的k8s捐献给CNCF。

众所周知,Prometheus出自google之手,已经成为监控界事实上的规范。再加上市面上的APM都是出自Dapper这篇论文,所以google的这个规范,自然会被引起重视。而且OpenCensus除了调用链追踪之外,还加上了度量指标,所以功能上更丰富一些。

这可苦了开发者。难道一个技术场景需要两种规范?

终于在2019年,两者和解,共同推出了OpenTelemetry,Telemetry是遥测术的意思,可以看到它的野心是非常大的。

2. OpenTelemetry包含什么?

关于日志、监控和调用链,两年之前,我曾画过一张图,但从中只能看到有哪些组件参与,只看图是模棱两可的。整个体系就是收集、处理、应用这大三类数据(logs、metrics、trace)。

时至今日,情况又有一些改变。目前的主流方案,是Promethus,加Grafana,加Telegraf(或者各种export),加Loki(ELKB),加Skywallking等。使用者需要了解多个系统,并给出有效的集成方案。

image.png

具体的数据流转和处理,每种结构都不尽相同,这也是为什么我一直强调分而治之的原因。但使用方式上,最好相差不要太大。无论后端的架构如何复杂,一个整体的外观将让产品变得更加清晰,你目前的工作,是不是也集中在此处呢?

上面的是xjjdog的原话,代表了作为一个使用者和规范的实践者,对于这三类数据(指标、日志、调用链)的迷思。现在这种情况,有所改善。因为OpenTelemetry规范,就想要把这些技术指标,全部囊括进来。它是一种厂商独立的规范和一组工具,可以让开发者变得更加幸福。但规范本来就不是一件容易的事,直到2021.02.10,OpenTelemetry 的1.0版本才算完成。

看一下OpenTelemetry 的官网吧,opentelemetry.io/。解决的,正是这些。

  • Traces 就是传统调用链的树
  • Metrics 运行时所抓取的指标值或计算的统计值,随着时间流逝会有不同
  • Logs 日志,比如异常日志或者额外附加信息

信息处理,当然也离不开采集、处理、展示三个阶段。

可以看到,相对于OpenTracing,多了Metrics这样的监控指标。随着分布式系统存储能力和计算能力的增加,我们有可能把这些信息放在一块了!由于提供了专用的sdk,统一的协议,以前难搞的跨平台,现在也不在话下。

3. 如何使用?

在使用之前,需要先搞懂几个术语。对于熟悉OpenTracing的同学来说,这都不叫事。

  • Traces 调用链,一个trrace包含多个Span。由root span,parent span和当前的span组成一棵树
  • Metrics 指标,包含Counter、ValueRecorder、SumObserver、ValueObserver等常见的应用场景
  • Context 每个span所包含的上下文信息,是一个全局唯一的标识
  • Context propagation propagation是传播的意思,它表示不同的服务之间的上下文传递。

OpenTelemetry的定义文件,是使用protobuf来描述的,所以天然具有跨平台性。信息的收集,有一个叫做opentelemetry-collector的组件来完成,它本质上是一个pipelines,这像极了kafka streaming等流式处理软件,也像极了logstash和flume这样的日志处理软件。

技术翻来覆去,来来回回,新瓶装旧酒而已。

image.png

一个典型的配置文件可能如下:

service:
  pipelines: # section that can contain multiple subsections, one per pipeline
    traces:  # type of the pipeline
      receivers: [otlp, jaeger, zipkin]
      processors: [memory_limiter, batch]
      exporters: [otlp, jaeger, zipkin]

其中包含三部分,receivers、processors、exporters。

  • receiver 这个的意思是怎么把其他平台的数据搞到自己的体系里来。比如接收特定的prometheus数据,然后转化成内循环的数据
  • processor 这些内循环数据就可以被processor处理,你可以在这里对数据进行一些更改,当然配置是一如既往的麻烦
  • exporter 想要把这些信息发送到什么平台去。实现了OpenTelemetry规范的组件,很容易的接收这些数据ba

这走的还是传统的三段式思路,不过在telegraf里,叫做input、output而已。不过也不用担心,厂商为了证明自己的系统符合标准,会主动去开发这些receiver和exporter。

接下来就好办的多了。各个版本的SDK,提供各种指标的API,对接平台就可以了。

3. 如何体验一下?

官方倒是有个例子,也省了我去做了。

https://opentelemetry.io/docs/java/instrumentation_examples/

它使用了Prometheus、Loki、Tempo、Grafana等组件,并使用springboot应用做了应用示例。可以看到,里面用了这么多的组件,自己搭建费时费力费脑子,走docker是最好的方式。

事实上,也是如此。

采用下面两步,即可完成部署。

mvn clean package docker:build
docker-compose up

嗯,很好看,也很好用。祝愿规范加快试试吧,因为目前有部分组件还是alpha版本。

image.png

作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,​进一步交流。​