OpenTelemetry-可观察性的新时代

时间:2019-09-17 来源:www.royal-astro.com

幸运的是,在2019KubeCon上海站,我听到了史蒂夫弗兰德斯关于OpenTelemetry的演讲。在Ops领域之前,两个网络红色项目,OpenTracing和OpenCensus,最终聚集在一起,可观察的一致性的标准化已经启动。

本文旨在窥探,希望与更多学生交换与可观察性相关的内容。

OpenTracing

OpenTracing开发了一种独立于平台的独立于供应商的跟踪协议,允许开发人员轻松添加或替换分布式跟踪系统。 2016年11月,CNCF技术委员会投票决定接受OpenTracing作为托管项目。这是CNCF的第三个项目。第一个是Kubernetes,第二个是普罗米修斯。可以看出,CNCF重视OpenTracing背后的可观察性。例如,着名的Zipkin和Jaeger遵循OpenTracing协议。

OpenCensus

从OpenTracing开始,每个人都会想,OpenCensus的秘诀是什么?对不起,您需要知道OpenCensus的创始人是Google,这是第一家提出跟踪概念的公司,OpenCensus是Google Dapper的社区版本。 OpenCensus和OpenTracing之间的最大区别在于除了跟踪之外,它还包括Metrics,它还可用于监控OpenCensus上的基本指标。不同的是OpenCensus不是一个简单的规范,他还包括数据收集。代理人和收藏家都完成了他们的大脑。 OpenCensus也有很多粉丝。最近的最大新闻是微软也宣布OpenCensus更加强大。

OpenTracing与OpenCensus

两套追踪框架,有很多粉丝,想要统一对方,该怎么办?首先来到PK,这是一个懒惰,直接在史蒂夫的地图上:

可以看出,OpenTracing和OpenCensus在功能和特性方面各有优缺点。 OpenTracing支持更多语言,与其他系统的联系不那么紧密; OpenCensus支持Metrics,从API到底层框架。由于功能和功能没有区别,因此从受欢迎程度和用户数量来看PK:

嗯,这是半斤。 OpenTracing有许多供应商可以关注(例如ElasticSearch,Uber,DataDog和国内SkyWalking)。谷歌和微软背后的OpenCensus足以支撑半边天。

最后,PK下降,没有胜利,我该怎么办?

变成了世界

所谓的世界将分为长期,长期必须结合,因为没有办法划分水平,谁有优点和缺点,让我们不去做,团结起来。所以OpenTelemetry结果出来了。

然后问题来了:可以重新统一,从头开始一个新项目吗?那跟随我的弟兄呢?不能失去我的兄弟。

请放心,这种事情肯定不会发生。要知道OpenTelemetry的启动器是OpenTracing和OpenCensus,该项目的第一个目标是与OpenTracing和OpenCensus兼容。对于使用OpenTracing或OpenCensus而无需重新修改的应用程序,可以访问OpenTelemetry。

核心工作

OpenTelemetry可以说是诞生时令人眼花缭乱的炫目:OpenTracing支持,OpenCensus支持,直接访问CNCF sanbox项目。但OpenTelemetry并不是要解决所有可观察性问题。他的核心工作主要集中在三个部分:

除了自己的协议之外,规范的制定,包括概念,协议和API,需要在这些规范与W3C和GRPC协议之间达成一致;相关SDK和工具的实现和集成,包括各种语言的SDK和代码注入。整合其他三方库(Log4j,LogBack等);采集系统的实施,目前使用OpenCensus的采集架构,包括Agent和Collector。

可以看出,OpenTelemetry仅执行数据规范,SDK和集合。它不涉及后端,视觉,警报等。官方建议使用Prometheus做Meends Backend和Jaeger做追踪后端。

查看上面的图片,您可能会遇到问题:度量标准,跟踪以及为什么没有添加日志记录?

事实上,Logging没有进入,主要有两个原因:

工作组的主要任务是统一OpenTracing和OpenCensus的概念,并尽早开发相应的SDK。记录是P2的优先级。他们还没有弄清楚如何将Logging集成到规范中,因为它还需要在CNCF中使用Fluentd。每个人都还没想过。

终极目标

OpenTelemetry的最终状态是将度量,跟踪和记录集成为CNCF可观察性的最终解决方案。

跟踪:为要处理的请求的整个生命周期提供跟踪路径。通常请求是在分布式系统中处理的,所以它也被称为分布式链路跟踪。

度量:提供系统内外各种维度的定量指标,通常包括计数器、量表、柱状图等。

日志记录:提供关于系统/进程的最详细的信息,如键变量、事件、访问记录等。

这三者对于可观测性是必不可少的:基于度量的警报发现异常,通过跟踪位置问题(可疑)模块,根据模块的特定日志详细信息找到错误的根本原因,最后根据该问题的经验调整度量。调查。增加或调整警报阈值等),以便您能够更早地检测/预防此类问题。

度量、跟踪和日志集成的关键

实现度量、跟踪和日志集成的关键是获得这三者之间的关系。我们可以关注最基本的信息,例如:时间、主机名(IP)、AppName。这些基本信息只能定位到特定的时间和模块,但很难继续挖掘,因此我们将把跟踪ID打印到日志中,从而实现跟踪和日志之间的关系。但这仍然不能解决很多问题:

如何将度量与其他两个度量相关联以提供更多的维度关联,例如请求的方法名、URL、用户类型、设备类型、地理位置等是如何一致的,并且可以在分布式系统下传播。

在OpenTelemetry中,我们尝试使用Context为度量标准,日志记录和跟踪提供统一的上下文。所有人都可以访问这些信息。 OpenTelemetry本身负责提供上下文存储和传播:

可以在任务/请求的执行周期中访问上下文数据,以提供统一的存储层,用于保存上下文信息并确保它可以在各种语言和处理模型下工作(例如单线程模型,线程池模型,回调函数)模型,Go常规模型等。)多维度的关联基于标签(或元)信息。标签内容由服务确定。例如,TrafficType是否用于区分生产流量和压力测量流量,DeviceType用于分析每种设备类型。 Data .提供分布式Context传播方法,例如通过W3C traceparent/tracestate头,GRPC协议等。

这是Yuri Shkuro的原型设计:

+ ------------------------------------------------- --- +

| |

+ ------------ +自定义应用程序逻辑或专用框架|

| | |

| + ------------------------------------- + ---------- - --- +

| |

| + --------- + - ---- + - ---- + - ------------------------- -------------------------------------------------- ------------------------------- + |

||||||||

||指标| |日志| | |痕迹+ - + |

|||||||||

| + ----------------- + - ---------- + - - + - ------------- -------------------------------------------------- ----------------------------------- + ||

| ^^^ ||

| + --- + -------------------------------------------- -------------------------------------------------- --------------------------------------- + ||

|||||

+ - >行李|||

||||

+ ------------------- + ----------------------------- -------------------------------------------------- ------------------------------------ + ||

|||

+ ----------------------------- + ------------------- -------------------------------------------------- -------------------------------------------------- ------------------------------ +

通用上下文传播层编组

插件

当前状态和后续路线

OpenTelemetry仍处于规划和原型设计阶段,许多细节仍在讨论中。目前,官方时间节奏如下:

2019年9月,SDK的主要语言版本(预发布版本)发布。 2019年11月,OpenTracing和OpenCensus正式安装(ReadOnly)确保在未来两年内与OpenTracing和OpenCensus SDK兼容

从Prometheus,OpenTracing,Fluentd到OpenTelemetry,Thanos项目,CNCF可以关注Cloud Native的可观察性,OpenTelemetry的出现标志着Metrics,Tracing和Logging的融合。

但OpenTelemetry并不是要解决所有客观性问题,还有很多工作要做,例如:

提供统一的后端存储。目前,三种类型的数据存储在不同的系统中,以提供计算和分析方法和最佳实践,例如AIOps相关的动态拓扑分析功能,如异常检测,根本原因分析等。/p>

有兴趣的学生可以看一下以下的一些文章,欢迎提出建议和讨论:

Pcdszlrz3y2w

作者:乙烯

http://www.whgcjx.com/bdsbIc.html