这个世界，又多了一点点抽象！
发布时间：2021-11-03 00:39:25 所属栏目：大数据 来源：互联网
导读：首先，我对群里这个动图心情十分复杂。又爱又恨。然后，我们来到正题。如果你常年在处理一些日志、监控方面的东西，一定会在一定程度上听过OpenTracing，像 Zipkin、Jaeger、SkyWalking都对其有很好的支持。但是可惜，OpenTracing已经成为过去式了，现在的A
|
首先，我对群里这个动图心情十分复杂。又爱又恨。
然后，我们来到正题。
如果你常年在处理一些日志、监控方面的东西，一定会在一定程度上听过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以前的文章。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号