OpenTelemetry-结束分布式追踪的江湖之乱

部分内容摘自：《OpenTelemetry中文文档-OT.md》

一、江湖乱象

分布式追踪，随着分布式系统的流行而兴起。在分布式系统中，往往存在一个单一的用户请求中，可能会需要大量微服务的处理后，才能完成这个请求，在微服务中的任何一个服务的失败或性能低下，都会对于用户请求的响应造成极大影响。随着业务的不断扩张，这个调用链的也就会越来越复杂。为了解决微服务架构中请求链路过长导致的问题定位和监控难问题，链路追踪产品也就应运而生。

目前的主流开源产品有Zipkin、Jaeger、PinPoint等。市场上产品虽多，但是各方都具有自己的数据采集协议以及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工具打通，统一用户的使用方式。但是随着项目的进展，野心也膨胀了，这个时候开始幻想为什么不把其它各种语言的相关采集都统一呢？于是乎，OpenCensus的场景进一步扩大了，不仅做了Metrics基础指标监控，还做了OpenTracing的老本行：分布式跟踪。

有个谷歌做亲爹已经够牛了，那再加入一个微软做干爹呢？是不是要起飞了？所以，对于OpenCensus的发展而言，微软的直接加入可以说是打破了之前的竞争平衡，间接导致了后面OpenTelemetry项目的诞生。

二、OpenTelemeTry横空出世

2019年4月24日，新项目成立，项目成员提交审查

2019年5月8日，各团队成立，开始各种语言下的工作

2019年5月20日，项目正式开始

2019年9月6日， Golang，Java，NodeJS和Python语言已经完成项目目标

2019年11月6日，项目进入收尾阶段

2019年11月20日，项目完成

OpenTelemetry

2019年，OpenTelemetry项目组成立，在2019年年底项目初步完成，

OpenTelemetry的核心工作目前主要集中在3个部分：

• 规范的制定和协议的统一，规范包含数据传输、API的规范，协议的统一包含：HTTP W3C的标准支持及GRPC等框架的协议标准
• 多语言SDK的实现和集成，用户可以使用SDK进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack等）进行集成支持；
• 数据收集系统的实现，当前是基于OpenCensus Service的收集系统，包括Agent和Collector。

由此可见，OpenTelemetry的自身定位很明确：数据采集和标准规范的统一。对于数据如何去使用、存储、展示、告警，官方是不涉及的，目前官方推荐的是使用Prometheus + Grafana做Metrics存储、展示，使用Jaeger做分布式追踪的存储和展示。

在上图中描述了服务产生数据，经由OpenTelemetry处理后转发至各数据展示及仓库的过程。左侧为产生数据的Service，在Service中通过agent或者SDK的形式来进行数据收集，再由agent或者SDK将数据上传至OpenTelemetry-Collector中进行数据处理，再将数据传输至右侧的数据存储、分析、展示平台，如Prometheus、Jaeger等（这里可以是任意平台，通过实现Exporter来完成）。

数据的采集端，官方给出的方案是使用OpenTelemetry的SDK/Agent进行采集，不过也可以使用其他的方式进行采集，比如企业自己开发的一个上报功能。在数据上传时，如果规范与OpenTelemetry自身规范发生冲突，也可以通过实现新的Collector中的Receiver来处理。在后续的OpenTelemetry-Collector介绍文档中会进行详细说明。

在上图中，并未添加日志的数据数据输出，日志的采集上报，在OpenTelemetry的SDK及Agent中均有实现，但是截止至目前<2021年1月>关于日志的处理官方还没有一个很好的方案，在OpenTelemtry-Collector中并没有针对于输出至ES或者其他日志分析平台的Exporter实现，这部分可能需要由开发者自己进行处理。

三、大一统

有了以上的背景知识，我们就可以顶一下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，最终实现监控数据标准的大一统。