OpenTelemetry可观察性的新时代

49次阅读

共计 4751 个字符,预计需要花费 12 分钟才能阅读完成。

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

前世

OpenTracing

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

OpenCensus

大家可能会想,既然有了 OpenTracing,OpenCensus 又来凑什么热闹?对不起,你要知道 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、还有国产的 SkyWalking),OpenCensus 背后 Google 和微软两个大佬就够撑起半边天了。
最终一场 PK 下来,没有胜负,怎么办?

OpenTelemetry

横空出世

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

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

核心工作

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

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

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

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

  1. 工作组目前主要的工作是在把 OpenTracing 和 OpenCensus 的概念尽早统一并开发相应的 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 画的原型设计:

  +----------------------------------------------------+
               |                                                    |
  +------------+ custom application logic or specialized frameworks |
  |            |                                                    |
  |            +-------------------------------------+--------------+
  |                                                  |
  |    +---------+ +------+ +--------+               |
  |    |         | |      | |        |               |
  |    | metrics | | logs | | traces +---+           |
  |    |         | |      | |        |   |           |
  |    +----+----+ +---+--+ +---+----+   |           |
  |         ^          ^        ^        |           |
  |   +-----+----------+--------+-----+  |           |
  |   |                               |  |           |
  +--->            baggage            |  |           |
      |                               |  |           |
      +---------------+---------------+  |           |
                      |                  |           |
+---------------------+------------------+-----------+-------------------+
             Universal context propagation layer <-----> marshaling
                                                          plugins

当前状态以及后续路线

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

  • 2019 年 9 月,发布主要语言版本的 SDK(Pre Release 版)
  • 2019 年 11 月,OpenTracing 和 OpenCensus 正式 sunsetted(ReadOnly)
  • 未来两年内,保证可以兼容 OpenTracing 和 OpenCensus 的 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


本文作者:元乙

阅读原文

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

正文完
 0