本文转载自微信公众号“小姐姐的味道”，作者小姐姐养的狗。转载本文请联系味觉小姐公众号。首先，我在群里对这部动画百感交集。又爱又恨。那么，我们进入正题。如果你常年和一些日志、监控的东西打交道，一定对OpenTracing有所耳闻，比如Zipkin、Jaeger、SkyWalking都对它有很好的支持。但不幸的是，OpenTracing已成为过去，现在APM世界由称为OpenTelemetry的规范统治。那是因为，作为一个标准，OpenTracing已经达到了它的要求。1.小历史很多同学已经开始喊了，我的OpenTracing还没学会，现在直接卡死了。这是谷歌的错。OpenTracing诞生于2016年11月，CNCF将其接纳为自有基金会的第三个项目。但是谷歌并不认为这个东西是一个标准，所以推出了自己的OpenCensus规范。什么是CNCF？cn不是指中国。它的全称是CloudNativeComputingFoundation，是Linux基金会下的一个基金会，可以理解为一个非营利组织。当时，谷歌将其k8s捐赠给了CNCF。众所周知，Prometheus由谷歌创建，已经成为监控行业事实上的标准。再加上市面上的APM都是从Dapper论文中衍生出来的，Google的这个规范自然会引起关注。而且，除了调用链跟踪，OpenCensus还增加了metrics，所以功能更强大。这对开发者来说很难。一个技术场景需要两个规范吗？终于在2019年，两人重归于好，共同推出了OpenTelemetry。Telemetry是遥测的意思。可见其野心之大。2.OpenTelemetry包括什么？关于日志、监控、调用链，我两年前画了一张图，但是只能看出里面涉及到哪些组件，光看图是模糊的。整个系统就是对这三类数据（logs、metrics、trace）进行收集、处理和应用。今天，情况发生了一些变化。目前主流方案是Promethus，加Grafana，加Telegraf（或各种export），加Loki（ELKB），加Skywallking等，用户需要了解多系统，提供有效的集成方案。每种结构具体的数据流向和处理方式都不一样，这也是我一直强调分而治之的原因。但在用法上，最好不要相差太大。不管后端架构有多复杂，整体的外观会让产品更加清晰。你现在的工作也集中在这里吗？以上是xjjdog的原话，代表一个用户和一个标准的Practitioner，关于这三类数据（指标、日志、调用链）的迷思。现在这种情况已经有所改善。由于OpenTelemetry规范，我们希望包括所有这些技术指标。它是独立于供应商的规范和工具集，可以让开发人员更满意。但规范并不是一件容易的事，OpenTelemetry的1.0版本直到2021.02.10才完成。看看OpenTelemetry的官方网站，https://opentelemetry.io/。解决的就是这些。Traces是传统调用链的树Metrics在运行时捕获的索引值或计算统计值。随着时间的推移，会出现不同的Logs日志，比如异常日志或者附加信息处理。当然，采集和加工也是密不可分的。,显示三个阶段。可以看出，相比OpenTracing，多了Metrics等监控指标。随着分布式系统的存储能力和计算能力的提高，我们有可能把这些信息拼凑起来！由于提供了专用的SDK和统一的协议，以前难以跨平台的问题现在没有了。日志监控等可以看xjjdog以前的文章。3.如何使用它？在使用它之前，您需要了解一些术语。对于熟悉OpenTracing的同学来说，这不是问题。Traces调用链，一个trace包含多个span。一棵树由rootspan、parentspan、currentspan组成Metrics指标，包括Counter、ValueRecorder、SumObserver、ValueObserver等常见的应用场景Context每个span包含的上下文信息是一个全局唯一标识Contextpropagationpropagation是Propagation的意思是它代表不同服务之间的上下文传输。OpenTelemetry的定义文件是用protobuf描述的，自然是跨平台的。信息的收集是通过一个叫做opentelemetry-collector的组件来完成的，它本质上是一个pipeline，和Kafkastreaming等流处理软件非常相似，也和logstash、flume等日志处理软件非常相似。技术是翻来覆去的，新瓶装旧酒。一个典型的配置文件可能如下：service:pipelines:#sectionthatcancontainmultiplesubsections,oneperpipelinetraces:#typeofthepipelinereceivers:[otlp,jaeger,zipkin]processors:[memory_limiter,batch]exporters:[otlp,jaeger,zipkin]其中包含三部分，receivers，加工商，出口商。receiver意思是如何从其他平台获取数据到自己的系统中。比如接收特定的prometheus数据，然后转换成一个内循环的数据处理器。这些内循环数据可以由处理器处理。您可以在此处对数据进行一些更改。当然，配置还是一如既往的麻烦。出口商希望将此信息发送到哪里？平台去。实现OpenTelemetry规范的组件可以轻松接收这些数据。这还是传统的三阶段思路，但是在telegraf中，叫做输入输出。不过不用担心，制造商会主动开发这些接收器和出口器，以证明他们的系统符合标准。下次会容易得多。每个版本的SDK都提供了各种指标的API，对接平台就可以了。3、如何体验？官方有例子，省得我去做。https://opentelemetry.io/docs/java/instrumentation_examples/使用Prometheus、Loki、Tempo、Grafana等组件，使用springboot应用制作应用示例。可以看到，里面用了这么多组件，自己搭建起来又费时费力，所以用docker是最好的方式。事实上，它是。使用以下两个步骤完成部署。mvncleanpackagedocker:builddocker-composeup嗯，它看起来不错，也很好用。我希望规范能够快速测试，因为一些组件仍处于alpha版本。作者简介：品味小姐姐（xjjdog），一个不允许程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。我的个人微信xjjdog0，欢迎加好友进一步交流。
