以前一直在思考对于一家互联网公司如何实战落地AIOPS,曾经在某厂践行过一些关于融合监控,日志和trace三个领域,而后结合算法实现AIOPS的工做。冥冥之中,总感受国外某些大厂,会折腾出一个标准,至于这个标准是什么,却不能特别清晰地说出来。
直到看到OpenTelemetry这个项目,结合本身以前的经历,感受这个项目对于运维,对于服务治理,对于AIOPS,相当重要。算法
两个有助于为云原生操做提供指标的开源项目已合并为一个项目。 Google的OpenCensus和Cloud Native Computing Foundation的OpenTracing的融合将被称为OpenTelemetry,并将由CNCF管理。后端
聚合背后的想法是建立一个完整的遥测系统,用于监控微服务和其余分布式系统,前两个项目的组织者说。它还将使最终用户的仪表服务过程更容易一些,特别是在已经很是丰富的云原生场景中。运维
遥测数据有多种形式,用户在进行整合时不想考虑多个品牌。他们应该只与一个项目集成,以得到他们想要的遥测。分布式
最终OpenTelemetry由一组集成的API和库以及经过代理和收集器的收集机制组成。这些组件用于生成,收集和描述有关分布式系统的遥测。该数据包括未来的基本上下文传播,分布式跟踪,度量和其余信号。 OpenTelemetry旨在使您能够轻松地从您的服务和您选择的后端获取关键的遥测数据。对于每种受支持的语言,它提供了一组API,库和数据规范,开发人员能够利用他们认为合适的任何组件。微服务
PS:性能
术语“可观察性”源于控制理论学科,指的是系统在其产生的遥测基础上的理解程度。设计
在软件中,可观察性一般是指由服务产生的遥测,并分为三个主要的垂直:代理
这些垂直方向紧密相连。度量标准可用于精肯定位,例如,行为不当行为的子集。与这些跟踪关联的日志可能有助于找到此行为的根本缘由。而后,能够根据此发现配置新指标,以便下次更早地发现此问题。日志
OpenTelemetry旨在将全部三个垂直组合成一组系统组件和特定于语言的遥测库。它旨在取代专一于跟踪的OpenTracing项目和专一于跟踪和指标的OpenCensus项目。生命周期
结合同为cncf项目的prometheus(metrics领域),jaeger(trace), fluentd(log),OpenTelemetry的愿景基本上具有很好的实战基础。融合merics和trace和log三大领域,至少在如下两个方向是有很是大的意义:
而对于一个互联网公司也有很大的启发,应该提早准备,在选型和实战merics和trace和log技术方案的时候,考虑到OpenTelemetry标准。