网站首页是什么,黑马程序员学费多少,分销微信小程序,头条推广平台有哪些CNCF 简介CNCF#xff08;Cloud Native Computing Foundation#xff09;#xff0c;中文为“云原生计算基金会”#xff0c;CNCF是Linux基金会旗下的基金会#xff0c;可以理解为一个非盈利组织。当年谷歌内部一直用于编排容器的Borg项目开源了#xff0c;为了该项目更好… CNCF 简介CNCFCloud 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我们先来分别看看这两个产品。OpenTracingOpenTracing制定了一套平台无关、厂商无关的协议标准使得开发人员能够方便的添加或更换底层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
