本文转载自微信公众号「小姐姐味道」，作者小姐姐养的狗。转载本文请联系小姐姐味道公众号。
首先，我对群里这个动图心情十分复杂。又爱又恨。
然后，我们来到正题。
如果你常年在处理一些日志、监控方面的东西，一定会在一定程度上听过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等。使用者需要了解多个系统，并给出有效的集成方案。
具体的数据流转和处理，每种结构都不尽相同，这也是为什么我一直强调分而治之的原因。但使用方式上，最好相差不要太大。无论后端的架构如何复杂，一个整体的外观将让产品变得更加清晰，你目前的工作，是不是也集中在此处呢?
上面的是xjjdog的原话，代表了作为一个使用者和规范的实践者，对于这三类数据(指标、日志、调用链)的迷思。现在这种情况，有所改善。因为OpenTelemetry规范，就想要把这些技术指标，全部囊括进来。它是一种厂商独立的规范和一组工具，可以让开发者变得更加幸福。但规范本来就不是一件容易的事，直到2021.02.10，OpenTelemetry 的1.0版本才算完成。
看一下OpenTelemetry 的官网吧，https://opentelemetry.io/。解决的，正是这些。
- Traces 就是传统调用链的树
- Metrics 运行时所抓取的指标值或计算的统计值，随着时间流逝会有不同
- Logs 日志，比如异常日志或者额外附加信息
信息处理，当然也离不开采集、处理、展示三个阶段。
可以看到，相对于OpenTracing，多了Metrics这样的监控指标。随着分布式系统存储能力和计算能力的增加，我们有可能把这些信息放在一块了!由于提供了专用的sdk，统一的协议，以前难搞的跨平台，现在也不在话下。
关于日志监控等等，可以看xjjdog以前的文章。
《主流监控一梭子》
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这样的日志处理软件。
技术翻来覆去，来来回回，新瓶装旧酒而已。
一个典型的配置文件可能如下：
- 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版本。
作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。
