OpenTelemetry - 云原生下可观测性的新标准
CNCF 简介
CNCF(Cloud Native Computing Foundation),中文为“云原生计算基金会”,CNCF是Linux基金会旗下的基金会,可以理解为一个非盈利组织。
当年谷歌内部一直用于编排容器的Borg项目开源了,为了该项目更好的发展,谷歌与Linux基金会一起创办了CNCF。同时,谷歌把Borg用Go语言重写,更名为Kubernetes并捐赠到CNCF。
成立这个组织的初衷或者愿景,简单说:
•推动云原生计算可持续发展;•帮助云原生技术开发人员快速地构建出色的产品;•CNCF通过建立社区、管理众多开源项目等手段来推广技术和生态系统发展。
APM
大家应该都听说过APM(Application Performance Monitoring),也应该听说过Distributed Tracing(分布式跟踪),其中后者是前者的子集。分布式跟踪该名词是随着微服务的流行而兴起的,主要是为了解决微服务架构中请求链路过长导致的定位和监控难问题。目前该领域有名的产品有:Jaeger、Pinpoint、Zipkin等等,可以说是竞争异常激烈,但是由此带来一个问题:每一家都有自己的一套数据采集标准和SDK,虽然几乎都是基于谷歌Dapper协议,但是彼此的实现是大相径庭的。为了解决这个问题,国外的大神们在之前创建了OpenTracing和OpenCensus,我们先来分别看看这两个产品。
OpenTracing
OpenTracing制定了一套平台无关、厂商无关的协议标准,使得开发人员能够方便的添加或更换底层APM的实现。
在2016年11月的时候发生了一件里程碑事件,CNCF.io接受OpenTracing,同时这也是CNCF的第三个项目,前两个都已经鼎鼎大名了:Kubernetes,和Prometheus,由此可见开源世界对APM的重视,对统一标准的重视和渴望。
遵循OpenTracing协议的产品有Jaeger、Zipkin等等。
OpenCensus
中国有句老话,既生瑜何生亮,OpenTracing本身出现的更早且更流行,为什么要有OpenCensus这个项目?
这里先补充一下背景知识,前面提到了分布式追踪,其实在APM领域,还有一个极其重要的监控子类:Metrics指标监控,例如cpu、内存、硬盘、网络等机器指标,grpc的请求延迟、错误率等网络协议指标,用户数、访问数、订单数等业务指标,都可以涵盖在内。
首先,该项目有个非常牛逼的亲爹:Google,要知道就连分布式跟踪的基础论文就是谷歌提出的,可以说谷歌就是亲爹无疑了。
其次,OpenCensus的最初目标并不是抢OpenTracing的饭碗,而是为了把Go语言的Metrics采集、链路跟踪与Go语言自带的profile工具打通,统一用户的使用方式。随着项目的进展,野心也膨胀了,这个时候开始幻想为什么不把其它各种语言的相关采集都统一呢?然后项目组发现了OpenTracing,突然发现,我K,作为谷歌,我们都没玩标准,你们竟然敢玩标准敢想着统一全世界?(此处乃作者的疯人疯语) 于是乎,OpenCensus的场景进一步扩大了,不仅做了Metrics基础指标监控,还做了OpenTracing的老本行:分布式跟踪。
有个谷歌做亲爹已经够牛了,那再加入一个微软做干爹呢?是不是要起飞了?所以,对于OpenCensus的发展而言,微软的直接加入可以说是打破了之前的竞争平衡,间接导致了后面OpenTelemetry项目的诞生。
OpenTracing vs OpenCensus
这里直接把 Steve Flanders的对比图拿了过来
功能特性
可以看到,OpenTracing和OpenCensus从功能和特性上来看,各有优缺点。OpenTracing支持的语言更多、相对对其他系统的耦合性要更低;OpenCensus支持Metrics、分布式跟踪,同时从API层一直到基础设施层都进行了支持。
开源社区
难分胜负?再来对比下社区活跃,我去,好像还是半斤八两,你有更广的使用群众基础,我有谷歌和微软就足矣。
所以,从上面可以看出,两个产品真的是各红遍半边天,但是作为开源项目,这种竞争未免太消耗资源了,对用户也十分不友好,咋么办?
OpenTelemetry
正所谓是:天下合久必分、分久必合,在此之时,必有枭雄出现:OpenTelemetry横空出世。
两个产品合并,首先要考虑的是什么?有过经验的同学都知道:如何让两边的用户能够继续使用。因此新项目首要核心目标就是兼容OpenTracing和OpenCensus。
OpenTelemetry的核心工作目前主要集中在3个部分:
1.规范的制定和协议的统一,规范包含数据传输、API的规范,协议的统一包含:HTTP W3C的标准支持及GRPC等框架的协议标准2.多语言SDK的实现和集成,用户可以使用SDK进行代码自动注入和手动埋点,同时对其他三方库(Log4j、LogBack等)进行集成支持;3.数据收集系统的实现,当前是基于OpenCensus Service的收集系统,包括Agent和Collector。
由此可见,OpenTelemetry的自身定位很明确:数据采集和标准规范的统一,对于数据如何去使用、存储、展示、告警,官方是不涉及的,我们目前推荐使用Prometheus + Grafana做Metrics存储、展示,使用Jaeger做分布式跟踪的存储和展示。
首先,再补充一下背景知识,之前提到了APM的两种监控子类:分布式跟踪和Metrics,其实还有第三种,就是Logging日志,目前常见的日志收集平台有EFK、Fluentd.
上图中可以看到,缺失了Logging,主要有以下原因:
1.优先级是在上面提到的三个核心工作上,Logging目前优先级相对较低(P2)2.Logging一般是通过三方平台完成收集,目前如何与分布式跟踪、Metrics的数据进行整合,官方还没有给出设计方案
大一统
有了以上的背景知识,我们就可以顶一下OpenTelemetry的终极目标了:实现Metrics、Tracing、Logging的融合及大一统,作为APM的数据采集终极解决方案。
•Tracing:提供了一个请求从接收到处理完成整个生命周期的跟踪路径,一次请求通常过经过N个系统,因此也被称为分布式链路追踪•Metrics:例如cpu、请求延迟、用户访问数等Counter、Gauge、Histogram指标•Logging:传统的日志,提供精确的系统记录
这三者的组合可以形成大一统的APM解决方案:
1.基于Metrics告警发现异常2.通过Tracing定位到具体的系统和方法3.根据模块的日志最终定位到错误详情和根源4.调整Metrics等设置,更精确的告警/发现问题
该如何融合?
在以往对APM的理解中,这三者都是完全独立的,但是随着时间的推移,人们逐步发现了三者之间的关联,例如我们可以把Tracing的TraceID打到Logging的日志中,这样可以把分布式链路跟踪和日志关联到一起,彼此数据互通,但是还存在以下问题:
1.如何把Metrics和其他两者关联起来2.如何提供更多维度的关联,例如请求的方法名、URL、用户类型、设备类型、地理位置等3.关联关系如何一致,且能够在分布式系统下传播
在OpenTelemetry中试图使用Context为Metrics、Logging、Tracing提供统一的上下文,三者均可以访问到这些信息,同时Context可以随着请求链路的深入,不断往下传播
•Context数据在Task/Request的执行周期中都可以被访问到•提供统一的存储层,用于保存Context信息,并保证在各种语言和处理模型下都可以工作(例如单线程模型、线程池模型、CallBack模型、Go Routine模型等)•多种维度的关联基于元信息(标签)实现,元信息由业务确定,例如:通过Env来区别是测试还是生产环境等•提供分布式的Context传播方式,例如通过W3C的traceparent/tracestate头、GRPC协议等
总结
从谷歌Dapper协议提出到现在已经很多年了,江湖也已经乱战了很多年,这次谷歌和微软下定决心结束江湖之乱,对于未来分布式系统的监控真的是非常巨大的利好消息,我们也有理由相信在这两家巨头的主导,该项目会越发展越好,未来会有越来越多的开源项目、框架、平台,原生的使用OpenTelemetry,最终实现监控数据标准的大一统。
引用
https://github.com/SpringLeee/docs-cn/blob/master/OT.md
最后
欢迎扫码关注我们的公众号 【全球技术精选】,专注国外优秀博客的翻译和开源项目分享,也可以添加QQ群 897216102
OpenTelemetry - 云原生下可观测性的新标准相关推荐
- 聚集云原生,可观测性的实践与探索 | 线下技术沙龙
导语 由腾讯云腾源会和 Apache SkyWalking 社区联合举办的 SkyWalkingDay 线下Meetup活动将于6月26日在北京举行,现场不仅有技术大咖带来满满的技术干货,还有Arip ...
- 解读云原生下的可观察性发展方向
简介:非常有幸参加了云原生社区Meetup北京站,有机会和众多业内的大牛一起讨论云原生相关的技术和应用,本次Meetup上我和大家分享了关于云原生下的可观察性相关的议题,本篇文章主要是视频的文字性总结 ...
- 解读:云原生下的可观察性发展方向
简介: 非常有幸参加了云原生社区Meetup北京站,有机会和众多业内的大牛一起讨论云原生相关的技术和应用,本次Meetup上我和大家分享了关于云原生下的可观察性相关的议题,本篇文章主要是视频的文字性总 ...
- Draft-微软出品的云原生下的本地开发辅助工具
一.介绍 Draft是微软Deis团队开源的一个用Go语言编写的容器应用开发辅助工具,用于帮助开发人员简化容器应用程序构建和部署的开发流程.Draft的设计思路在于,允许开发人员在不了Docker和K ...
- 云原生下的DevOps与持续交付
课程概要 2009年,一场演讲在O'Reilly Velocity大会上一炮而红,演讲中有一句话深得人心:"由于开发和运维需要在Flickr(一个图片存储和视频托管网站)上合作,这导致开发者 ...
- 万物云原生下的服务进化 | 京东云技术团队
导读: 在万物云原生下的环境下,Java的市场份额也因耗资源.启动慢等缺点,导致在云原生环境里被放大而降低,通过这篇文章,读者可以更好地了解如何在云原生环境下通过升级相关版本和使用GraalVM打出原 ...
- 2022云原生网络趋势 | K8s托管整个基础设施、多云、边缘计算、安全等场景,将云原生网络带向新战场
云原生技术在飞速发展的过程中不断地进入更多的行业和领域,作为云原生网络发展的见证者.亲历者,Kube-OVN Team对大量用户的技术选型.应用场景.落地实践经验进行分析,看到了一套不同于以往的网络发 ...
- 腾讯牵头成立CSA云原生安全工作组,助力标准制定和产业落地
2021年12月21日,CSA召开线上会议,正式宣布成立云原生安全工作组,腾讯和绿盟担任联合组长单位,中国工商银行.中国电信.浪潮云等安全技术使用方,深圳国家金融科技测评中心.广州赛宝认证中心等检测机 ...
- 云原生下日志方案的架构设计
上一篇中我们介绍了为什么需要一个日志系统.为什么云原生下的日志系统如此重要以及云原生下日志系统的建设难点,相信DevOps.SRE.运维等同学看了是深有体会的.本篇文章单刀直入,会直接跟大家分享一下如 ...
最新文章
- git原理及常见使用方法
- Android -- DrawerLayout
- 从几十人小药厂走出的惊天抗癌神药
- 博主谈:聊聊我们说的网站优化
- Unity3D面试——真实的面试,unity3d面试
- [原创]Zenoss配置入门-邮件短信通知
- 7-6 0-1背包 (20 分)(思路加详解+网格做法+动态规划)Come Baby !!!!!!!!!!!!!!
- Mongodb 分片与副本集
- Windows环境下搭建Tomcat
- Hadoop 序列化
- 《统计学习方法》——朴素贝叶斯法
- 运行深度学习代码时报错RuntimeError: CUDA out of memory. Tried to allocate 482.00 MiB
- 思迅商云8修改服务器端口,思迅商云8 sql server端口打开失败1433
- 大华服务器装系统,clonezilla安装系统理论篇
- java公寓报修管理系统_学生公寓报修管理系统.pdf
- Lucene(全文检索框架) 简单实例
- 程序员github头像_给新程序员的5个GitHub技巧
- WMS系统开发总结-移库管理-下架与上架
- 创业失败那天我在做什么
- DTC社群运营怎么做?