有幸在2019KubeCon上海站听到Steve Flanders关于OpenTelemetry的演讲,之前Ops领域两个网红项目OpenTracing和OpenCensus终于走到了一起,可观察性统一的标准化已经扬帆起航。
这篇文章旨在抛砖引玉,希望能够和更多的同学一起交流可观察性相关的内容。

前世

OpenTracing

OpenTracing制定了一套平台无关、厂商无关的Trace协议,使得开发人员能够方便的添加或更换分布式追踪系统的实现。在2016年11月的时候CNCF技术委员会投票接受OpenTracing作为Hosted项目,这是CNCF的第三个项目,第一个是Kubernetes,第二个是Prometheus,可见CNCF对OpenTracing背后可观察性的重视。比如大名鼎鼎的Zipkin、Jaeger都遵循OpenTracing协议。

OpenSensus

大家可能会想,既然有了OpenTracing,OpenSensus又来凑什么热闹?对不起,你要知道OpenSensus的发起者可是谷歌,也就是最早提出Tracing概念的公司,而OpenSensus也就是Google Dapper的社区版。OpenSensus和OpenTracing最大的不同在于除了Tracing外,它还把Metrics也包括进来,这样也可以在OpenSensus上做基础的指标监控;还一点不同是OpenSensus并不是单纯的规范制定,他还把包括数据采集的Agent、Collector一股脑都搞了。OpenSensus也有众多的追随者,最近最大的新闻就是微软也宣布加入,OpenSensus可谓是如虎添翼。

OpenTracing vs OpenSensus

两套Tracing框架,都有很多追随者,都想统一对方,咋办?首先来PK啊,这里偷个懒,直接上Steve的图:

可以看到,OpenTracing和OpenCensus从功能和特性上来看,各有优缺点,半斤八两。OpenTracing支持的语言更多、相对对其他系统的耦合性要更低;OpenCensus支持Metrics、从API到基础框架都实现了个便。既然从功能和特性上分不出高下,那就从知名度和用户数上来PK吧:

好吧,又是半斤八两,OpenTracing有很多厂商追随(比如ElasticSearch、Uber、DataDog、还有国产的SkyWalking),OpenCensus背后Google和微软两个大佬就够撑起半边天了。
最终一场PK下来,没有胜负,怎么办?

OpenTelemetry

横空出世

所谓天下合久必分、分久必合,既然没办法分个高低,谁都有优劣势,咱们就别干了,统一吧。于是OpenTelemetry横空出世。

那么问题来了:统一可以,起一个新的项目从头搞吗?那之前追随我的弟兄们怎么办?不能丢了我的兄弟们啊。
放心,这种事情肯定不会发生的。要知道OpenTelemetry的发起者都是OpenTracing和OpenSensus的人,所以项目的第一宗旨就是:兼容OpenTracing和OpenSensus。对于使用OpenTracing或OpenSensus的应用不需要重新改动就可以接入OpenTelemetry。

核心工作

OpenTelemetry可谓是一出生就带着无比炫目的光环:OpenTracing支持、OpenSensus支持、直接进入CNCF sanbox项目。但OpenTelemetry也不是为了解决可观察性上的所有问题,他的核心工作主要集中在3个部分:

  1. 规范的制定,包括概念、协议、API,除了自身的协议外,还需要把这些规范和W3C、GRPC这些协议达成一致;
  2. 相关SDK、Tool的实现和集成,包括各类语言的SDK、代码自动注入、其他三方库(Log4j、LogBack等)的集成;
  3. 采集系统的实现,目前还是采用OpenSensus的采集架构,包括Agent和Collector。

可以看到OpenTelemetry只是做了数据规范、SDK、采集的事情,对于Backend、Visual、Alert等并不涉及,官方目前推荐的是用Prometheus去做Metrics的Backend、用Jaeger去做Tracing的Backend。
​​​​​​​

看了上面的图大家可能会有疑问:Metrics、Tracing都有了,那Logging为什么也不加到里面呢?
其实Logging之所以没有进去,主要有两个原因:

  1. 工作组目前主要的工作是在把OpenTracing和OpenSensus的概念尽早统一并开发相应的SDK,Logging是P2的优先级。
  2. 他们还没有想好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的关联。但这还是解决不了很多问题:

  1. 如何把Metrics和其他两者关联起来
  2. 如何提供更多维度的关联,例如请求的方法名、URL、用户类型、设备类型、地理位置等
  3. 关联关系如何一致,且能够在分布式系统下传播

在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画的原型设计:

  1. +----------------------------------------------------+
  2. | |
  3. +------------+ custom application logic or specialized frameworks |
  4. | | |
  5. | +-------------------------------------+--------------+
  6. | |
  7. | +---------+ +------+ +--------+ |
  8. | | | | | | | |
  9. | | metrics | | logs | | traces +---+ |
  10. | | | | | | | | |
  11. | +----+----+ +---+--+ +---+----+ | |
  12. | ^ ^ ^ | |
  13. | +-----+----------+--------+-----+ | |
  14. | | | | |
  15. +---> baggage | | |
  16. | | | |
  17. +---------------+---------------+ | |
  18. | | |
  19. +---------------------+------------------+-----------+-------------------+
  20. Universal context propagation layer <-----> marshaling
  21. plugins

当前状态以及后续路线

目前OpenTelemetry还处于策划和原型阶段,很多细节的点还在讨论当中,目前官方给的时间节奏是:

  • 2019年9月,发布主要语言版本的SDK(Pre Release版)
  • 2019年11月,OpenTracing和OpenSensus正式sunsetted(ReadOnly)
  • 未来两年内,保证可以兼容OpenTracing和OpenSensus的SDK

总结

从Prometheus、OpenTracing、Fluentd到OpenTelemetry、Thanos这些项目的陆续进入就可以看出CNCF对于Cloud Native下可观察性的重视,而OpenTelemetry的出现标志着Metrics、Tracing、Logging有望全部统一。

但OpenTelemetry并不是为了解决客观性上的所有问题,后续还有很多工作需要进行,例如:

  • 提供统一的后端存储,目前三类数据都是存储在不同系统中
  • 提供计算、分析的方法和最佳实践,例如动态拓扑分析
  • 统一的可视化方案
  • AIOps相关能力,例如Anomaly Detection、Root Cause Analysis等

参考

有兴趣的同学可以看看下面的一些文章,欢迎各位指教和探讨:
https://opentracing.io/
https://opencensus.io/
https://opentelemetry.io/
https://thenewstack.io/opentracing-opencensus-merge-into-a-single-new-project-opentelemetry/
https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
https://www.cncf.io/blog/2016/10/11/opentracing-joins-the-cloud-native-computing-foundation/
https://medium.com/jaegertracing/embracing-context-propagation-7100b9b6029a
https://github.com/open-telemetry/opentelemetry-specification/issues/9
https://docs.google.com/document/d/1UxrEYOaQlF_E4gtiPoFmcZ4YKKe1GxohvCvQDuwvD1I/edit?source=post_page---------------------------#heading=h.pcdszlrz3y2w
https://medium.com/jaegertracing/jaeger-and-opentelemetry-1846f701d9f2

本文作者:元乙

原文链接

本文为云栖社区原创内容,未经允许不得转载。

OpenTelemetry-可观察性的新时代的更多相关文章

  1. Vimer的福音 新时代的Vim C++自动补全插件 clang_complete

    使用vim的各位肯定尝试过各种各样的自动补全插件,比如说大名鼎鼎的 OmniCppComplete .这一类的插件都是对 Ctags 生成的符号表进行字符串匹配来获得可能的补全项.他们在编写 C 代码 ...

  2. MEAN实践——LAMP的新时代替代方案(上)

    摘要:90 年代,LAMP 曾风靡一时,然而随着需求的变迁和数据流量的激增,LAMP 已不可避免的走下神坛.近日,在 MongoDB Blog 中,Dana Groce 介绍了一个基于新时代架构的实践 ...

  3. 新时代的Vim C++自动补全插件 clang_complete

    Vimer的福音 新时代的Vim C++自动补全插件 clang_complete   使用vim的各位肯定尝试过各种各样的自动补全插件,比如说大名鼎鼎的 OmniCppComplete .这一类的插 ...

  4. 全景智慧城市——VR全景,开启VR营销新时代

    全景是一种新兴的富媒体技术. 与视频.声音.图片等传统主流媒体最大的区别是"可操作,可交互". 全景给人以三维立体感觉的实景360°全方位图像,此图像最大的三个特点: 全方位:展示 ...

  5. 2018 dnc 公司案例大全,迎接.NET Core开源新时代

    2018 dnc 公司案例大全,迎接.NET Core开源新时代   dnc = .NET Core.dotnet Core dnc是微软新一代主力编程平台,开源.免费.跨平台.轻量级.高性能,支持L ...

  6. 论 大并发 下的 乐观锁定 Redis锁定 和 新时代事务

    在 <企业应用架构模式> 中 提到了 乐观锁定, 用 时间戳 来 判定 交易 是否有效, 避免 传统事务 的 表锁定 造成 的 瓶颈 . 在 现在的 大并发 的 大环境下, 传统事务 及其 ...

  7. C#情怀与未来,怨天尤人还是抓住机会,能否跟上dnc新时代浪潮?

    C#情怀与未来,怨天尤人还是抓住机会,能否跟上dnc新时代浪潮?   经常看到有.NET圈子在讨论是否应该转其它语言   C#情怀是一方面,如果觉得C#未来没前途,光靠情怀是撑不住的, 建议对C#未来 ...

  8. 3星|《科技投资新时代》:TMT行业资讯汇编

    科技投资新时代:TMT投资方法.趋势与热点聚焦 全书共6章,前4章是一些投资与分析的基本方法与技巧,第5章集中讲通信行业的现状与趋势,第6章讲大数据.物联网.全面屏等TMT行业热点. 总体来说数据.信 ...

  9. 新时代运维重器 Tencent Hub 最佳实践——云+未来峰会开发者专场回顾

    欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 演讲者:邹辉 腾讯云 PaaS 产品总监 背景:5月23-24日,以"焕启"为主题的腾讯"云+未来" ...

  10. WebAssembly,Web的新时代

    在浏览器之争中,Chrome凭借JavaScript的卓越性能取得了市场主导地位,然而由于javascript的无类型特性,导致其运行时消耗大量的性能做为代价,这也是JavaScript的瓶颈之一.W ...

随机推荐

  1. linux管道和tee命令

    ps -ef | grep docker 等价于 ps -ef &> >(grep docker) cat a.log | tee b.txt 等价于 cat a.log & ...

  2. 左神算法书籍《程序员代码面试指南》——2_03删除链表的中间节点和a/b处的节点

    [题目]给定链表的头节点head,实现删除链表的中间节点的函数.例如:不删除任何节点:1->2,删除节点1:1->2->3,删除节点2:1->2->3->4,删除节 ...

  3. PAT甲级——A1015 Reversible Primes

    A reversible prime in any number system is a prime whose "reverse" in that number system i ...

  4. python学习笔记1_import与from方法总结

    一.模块&包简介 模块:所谓模块就是一个.py文件,用来存放变量,方法的文件,便于在其他python文件中导入(通过import或from). 包(package): 包是更大的组织单位,用来 ...

  5. day65——day69

    目录 DAY65 课堂笔记 1.vue实例 2.插值表达式 3.文本指令 4.面向对象js 5.js函数补充 6.事件指令 7.属性指令 DAY66 课堂笔记 1.表单指令 2.条件指令 3.循环指令 ...

  6. Hibernate-HQL-Criteria-查询优化

    1 查询总结 oid查询-get 对象属性导航查询 HQL Criteria 原生SQL 2 查询-HQL语法 2.1 基础语法 2.2 进阶语法 排序 条件 分页 聚合 投影 多表查询 SQL HQ ...

  7. 2019-8-31-dotnet-新项目格式与对应框架预定义的宏

    title author date CreateTime categories dotnet 新项目格式与对应框架预定义的宏 lindexi 2019-08-31 16:55:58 +0800 201 ...

  8. Django定义全局变量

    定义全局变量,在项目的任何位置都可以获取到变量的值 在include App=>include文件夹下=>context_processors.py 里定义需要获取的变量 #!/usr/b ...

  9. CENTOS 7更换系统启动默认内核

    本文不再更新,可能存在内容过时的情况,实时更新请移步原文地址:CENTOS 7更换系统启动默认内核: 环境: CentOS Linux release 7.6.1810 (Core) : 1.查看当前 ...

  10. CentOS如何升级openssl到最新版本

    本文不再更新,可能存在内容过时的情况,实时更新请移步原文地址:CentOS如何升级openssl到最新版本: 环境信息 CentOS Linux release 7.6.1810 (Core): Op ...