摄影学习网站,网站营销 海外,三网合一网站开发是什么,网站建设和网页制作有幸在2019KubeCon上海站听到Steve Flanders关于OpenTelemetry的演讲#xff0c;之前Ops领域两个网红项目OpenTracing和OpenCensus终于走到了一起#xff0c;可观察性统一的标准化已经扬帆起航。 这篇文章旨在抛砖引玉#xff0c;希望能够和更多的同学一起交流可观察性相关的… 有幸在2019KubeCon上海站听到Steve Flanders关于OpenTelemetry的演讲之前Ops领域两个网红项目OpenTracing和OpenCensus终于走到了一起可观察性统一的标准化已经扬帆起航。 这篇文章旨在抛砖引玉希望能够和更多的同学一起交流可观察性相关的内容。 前世
OpenTracing
OpenTracing制定了一套平台无关、厂商无关的Trace协议使得开发人员能够方便的添加或更换分布式追踪系统的实现。在2016年11月的时候CNCF技术委员会投票接受OpenTracing作为Hosted项目这是CNCF的第三个项目第一个是Kubernetes第二个是Prometheus可见CNCF对OpenTracing背后可观察性的重视。比如大名鼎鼎的Zipkin、Jaeger都遵循OpenTracing协议。
OpenCensus
大家可能会想既然有了OpenTracingOpenCensus又来凑什么热闹对不起你要知道OpenCensus的发起者可是谷歌也就是最早提出Tracing概念的公司而OpenCensus也就是Google Dapper的社区版。OpenCensus和OpenTracing最大的不同在于除了Tracing外它还把Metrics也包括进来这样也可以在OpenCensus上做基础的指标监控还一点不同是OpenCensus并不是单纯的规范制定他还把包括数据采集的Agent、Collector一股脑都搞了。OpenCensus也有众多的追随者最近最大的新闻就是微软也宣布加入OpenCensus可谓是如虎添翼。
OpenTracing vs OpenCensus
两套Tracing框架都有很多追随者都想统一对方咋办首先来PK啊这里偷个懒直接上Steve的图 可以看到OpenTracing和OpenCensus从功能和特性上来看各有优缺点半斤八两。OpenTracing支持的语言更多、相对对其他系统的耦合性要更低OpenCensus支持Metrics、从API到基础框架都实现了个便。既然从功能和特性上分不出高下那就从知名度和用户数上来PK吧 好吧又是半斤八两OpenTracing有很多厂商追随比如ElasticSearch、Uber、DataDog、还有国产的SkyWalkingOpenCensus背后Google和微软两个大佬就够撑起半边天了。 最终一场PK下来没有胜负怎么办
OpenTelemetry
横空出世
所谓天下合久必分、分久必合既然没办法分个高低谁都有优劣势咱们就别干了统一吧。于是OpenTelemetry横空出世。
那么问题来了统一可以起一个新的项目从头搞吗那之前追随我的弟兄们怎么办不能丢了我的兄弟们啊。 放心这种事情肯定不会发生的。要知道OpenTelemetry的发起者都是OpenTracing和OpenCensus的人所以项目的第一宗旨就是兼容OpenTracing和OpenCensus。对于使用OpenTracing或OpenCensus的应用不需要重新改动就可以接入OpenTelemetry。
核心工作
OpenTelemetry可谓是一出生就带着无比炫目的光环OpenTracing支持、OpenCensus支持、直接进入CNCF sanbox项目。但OpenTelemetry也不是为了解决可观察性上的所有问题他的核心工作主要集中在3个部分
规范的制定包括概念、协议、API除了自身的协议外还需要把这些规范和W3C、GRPC这些协议达成一致相关SDK、Tool的实现和集成包括各类语言的SDK、代码自动注入、其他三方库Log4j、LogBack等的集成采集系统的实现目前还是采用OpenCensus的采集架构包括Agent和Collector。
可以看到OpenTelemetry只是做了数据规范、SDK、采集的事情对于Backend、Visual、Alert等并不涉及官方目前推荐的是用Prometheus去做Metrics的Backend、用Jaeger去做Tracing的Backend。
看了上面的图大家可能会有疑问Metrics、Tracing都有了那Logging为什么也不加到里面呢 其实Logging之所以没有进去主要有两个原因
工作组目前主要的工作是在把OpenTracing和OpenCensus的概念尽早统一并开发相应的SDKLogging是P2的优先级。他们还没有想好Logging该怎么集成到规范中因为这里还需要和CNCF里面的Fluentd一起去做大家都还没有想好。
终极目标
OpenTelemetry的终态就是实现Metrics、Tracing、Logging的融合作为CNCF可观察性的终极解决方案。
Tracing提供了一个请求从接收到处理完毕整个生命周期的跟踪路径通常请求都是在分布式的系统中处理所以也叫做分布式链路追踪。 Metrics提供量化的系统内/外部各个维度的指标一般包括Counter、Gauge、Histogram等。 Logging提供系统/进程最精细化的信息例如某个关键变量、事件、访问记录等。
这三者在可观察性上缺一不可基于Metrics的告警发现异常通过Tracing定位问题可疑模块根据模块具体的日志详情定位到错误根源最后再基于这次问题调查经验调整Metrics增加或者调整报警阈值等以便下次可以更早发现/预防此类问题。
Metrics、Tracing、Logging融合的关键
实现Metrics、Tracing、Logging融合的关键是能够拿到这三者之间的关联关系.其中我们可以根据最基础的信息来聚焦例如时间、Hostname(IP)、APPName。这些最基础的信息只能定位到一个具体的时间和模块但很难继续Digin于是我们就把TraceID把打印到Log中这样可以做到Tracing和Logging的关联。但这还是解决不了很多问题
如何把Metrics和其他两者关联起来如何提供更多维度的关联例如请求的方法名、URL、用户类型、设备类型、地理位置等关联关系如何一致且能够在分布式系统下传播
在OpenTelemetry中试图使用Context为Metrics、Logging、Tracing提供统一的上下文三者均可以访问到这些信息由OpenTelemetry本身负责提供Context的存储和传播
Context数据在Task/Request的执行周期中都可以被访问到提供统一的存储层用于保存Context信息并保证在各种语言和处理模型下都可以工作例如单线程模型、线程池模型、CallBack模型、Go Routine模型等多种维度的关联基于Tag或者叫meta信息实现Tag内容由业务确定例如通过TrafficType来区别是生产流量还是压测流量、通过DeviceType来分析各个设备类型的数据...提供分布式的Context传播方式例如通过W3C的traceparent/tracestate头、GRPC协议等
下面是Yuri Shkuro画的原型设计 ----------------------------------------------------| |------------ custom application logic or specialized frameworks || | || ---------------------------------------------------| || --------- ------ -------- || | | | | | | || | metrics | | logs | | traces --- || | | | | | | | || -------- ----- ------- | || ^ ^ ^ | || ---------------------------- | || | | | |--- baggage | | || | | |------------------------------ | || | |
---------------------------------------------------------------------Universal context propagation layer ----- marshalingplugins
当前状态以及后续路线
目前OpenTelemetry还处于策划和原型阶段很多细节的点还在讨论当中目前官方给的时间节奏是
2019年9月发布主要语言版本的SDKPre Release版2019年11月OpenTracing和OpenCensus正式sunsettedReadOnly未来两年内保证可以兼容OpenTracing和OpenCensus的SDK
总结
从Prometheus、OpenTracing、Fluentd到OpenTelemetry、Thanos这些项目的陆续进入就可以看出CNCF对于Cloud Native下可观察性的重视而OpenTelemetry的出现标志着Metrics、Tracing、Logging有望全部统一。
但OpenTelemetry并不是为了解决客观性上的所有问题后续还有很多工作需要进行例如
提供统一的后端存储目前三类数据都是存储在不同系统中提供计算、分析的方法和最佳实践例如动态拓扑分析统一的可视化方案AIOps相关能力例如Anomaly Detection、Root Cause Analysis等
原文链接 本文为云栖社区原创内容未经允许不得转载。