前言

前文中提到了微盟当前使用的前端APM系统，在其中我们使用了OpenTracing最为调用链规范标准。但在实际使用的过程，我们渐渐发觉了一些使用上的痛点，例如：

• 光依据调用链无法很好的定位问题
• 调用链与日志系统关联性差，定位具体问题耗时较长
• 切换数据后端成本较高
• 内部团队有些使用的规范不同，需要适配多套规范

从而我们也开始寻找是否有更优的解决方案，而OpenTelemetry逐渐走入我们的视野。

本文是笔者学习之后的一些总结和分析，希望能给正好想要了解这块内容的你一些帮助。

简介

随着软件应用从单片机结构向分布式微服务体系转变，应用监控(Monitoring)和应用观测(Observability)也的需求也随之提升。应用观测与应用监控虽然存在着一些相同的定义，但是还是存在着一些差别。

应用监控和应用观测的目的都是为了发现应用程序中的问题。但是，应用监控的目的是为了捕获已知的问题，并将其显示在仪表盘上，用以了解其发生问题的原因和其发生的具体时间。

而应用观测则采用更底层的方式，即开发人员通过调试代码的方式从而了解程序的内部状态。因此，应用观测是为了帮助监控应用程序的未知问题的最新发展。

而其中帮助进行应用观测的三大支柱，他们分别是日志(logs)、指标(metrics)、调用链(traces)。

• 指标(Metrics)指出了是否存在问题，通常是通过告警「发现」
• 调用链(Traces)能标明问题点在哪里 「定位」
• 日志(Logs)帮助你定位到产生问题的根本原因 「分析」

应用观测提供了以下几个好处：

• 能够找出本来或许难以发现的隐患。通常来说，解决生产问题是一场灾难。
• 降低告警疲劳
• 更快的发布产品
• 提高自动化程度
• 提高开发人员的生产力

根据Gartner的数据表明，到2024年，30%的企业将利用应用观测用以提升数字业务的绩效。这相比2020年的10%有所提升。

什么是OpenTracing？

在调用链概念出现之前，日志是用来帮助我们理解应用程序中发生情况的唯一途径。大多数的应用程序在他们运行的服务器上创建日志。然而，对于分布式系统来说，光靠日志是不够的，因为光靠日志定位问题的具体位置是一项巨大的挑战。但是调用链则可以非常方便的处理这种场景，因为其可以完整的追踪一个请求的开始到结束所经过的所有节点。

但哪怕调用链提供的对分布式系统链路的可见性，插桩调用链仍是一项单调乏味的工作。每种可能被追踪的工具都以自己的标准进行工作，并且它们自身也在不停迭代。因此，开发人员很难在整个软件过程中只使用其中一种工具，而其不同的对接和适用标准常常会对使用人员造成困扰。这就是OpenTracing大放异彩的地方。

OpenTracing是一套与供应商无关的开源API，允许开发人员将调用链打点能力添加到它们的代码中。它是一个用于插桩的标准框架，而不是一个特定的，可安装的程序。其目的是为所有可用的追踪工具提供标准的规范。其提供的API提供了九种不同的语言，包括Java、JavaScript和Python等。

OpenTracing的功能介绍

OpenTracing由以下四个主要的组成部分组成，他们分别是：

• Tracer
• Tracer是调用链API的入口。Tracer用于创建Spans，Spans允许我们从外部来源提取和注入追踪信息。
• Span
• Span是调用链中的主要构成勾结或工作单元。例如你如果发起了一个Web请求则会创建一个新的Span，而其被称为根Span「root span」，如果该请求在其工作流中发起了另一个请求，则第二个请求则会创建出一个子Span，如此循环直至完成整个请求过程。期间产生的所有Span通过一个相同的Trace Id进行关联，这一系列具有链式关系的Spans就被称为调用链。Span可以支持很多复杂的工作流，甚至包括异步消息的传递。
• SpanContext
• SpanContext是Span的一种可序列化内容，通过它可以跨进城边界的来传输Span信息。其内容通常包含Trace Id，Span Id还有一些行李项(baggae item，用于向后续的span传递一些信息)。
• References
• References是Spans之间建立连接的描述，目前有两种类型，ChildOf 和 FollowsFrom。

什么是OpenTelemetry?

遥测数据(Telemetry data)是跨科学领域的通用术语。它描述一种从远程位置收集数据集用于测量系统健康状况的行为。而在DevOps中，系统指的的就是软件应用，而我们收集的数据就是日志、调用链和指标了。

OpenTelemetry是一个开源框架，其包含用于收集遥测数据的工具、API和SDK。然后被收集到的数据会被发送到后端平台进行分析用以了解应用程序的状态。OpenTelemetry是一个CNCF(Cloud Native Computing Foundation，云原生计算基金会)的孵化项目，并于2019年5月合并了OpenTracing和OpenCensus。

OpenTelemetry旨在创建一个收集可观测性数据的标准格式。在OpenTelemetry规范被提出前，跨不同应用程序收集遥测数据的规范是不一致的。这对于开发人员来说是一个相当大的负担。OpenTelemetry提供了一个与供应商无关的API以及库为可观测监控提供了一个标准。它能为公司节省下本来用于建立收集遥测数据机制而花费的大量宝贵时间。

OpenTelemetry相关的安装和使用方法可以参考官方的引导

OpenTelemetry的功能介绍

上文提到，OpenTelemetry是一整套完整的软件框架，那我们必须了解其中几个关键组成部分，才能理解其是如何工作的，它们如下：

API

API通过插桩你的应用来创建调用链、指标和日志。这些API是基于特定语言的，目前已经支持大部分主流语言，例如: Java、.Net、Python和JavaScript。

SDK

SDK是另一个基于语言的组件，其作为API与数据导出的中介。SDK定义了类似配置、数据处理和数据导出等概念。SDK也很能好的处理事务采样以及请求过滤。

收集器(Collector)

收集器用于收集、处理和导出遥测数据。它主要充当一个与供应商无关的代理。虽然它不是一个必不可少的组件，但由于它对于接收和发送应用遥测数据到后端具有很大的灵活性，所以其还是很有帮助的。举个例子，如果必须，你可以处理来此OTLP(opentelemetry本身提供的数据格式)、Jaeger及Prometheus的多种数据格式，并将其发送到各种后端应用。

导出器(Exporter)

可以通过配置导出器来选择你希望将遥测数据发送至那个后端。导出器将后端配置从应用插桩中分离出来。因此，你可以很轻松的更换希望处理数据的后端而无需更换插桩。

OpenTracing和OpenTelemetry的区别

OpenTracing和OpenTelemetry都是开源项目，旨在提供与供应商无关的解决方案。然而，OpenTelemetry是最新的解决方案，并且它是集OpenTracing与OpenCensus两者之大成者。因此，它比OpenTracing更为健壮。

OpenTracing仅仅在分布式应用中记录调用链数据，而OpenTelemetry收集所有类型的遥测数据例如日志、指标和调用链。此外，OpenTelemtry是一个开箱即用的API、SDK和库的合集。还有一个关键的优势就是OpenTelemetry能够快速改变处理遥测数据的后端。

综上所述，OpenTelemetry比OpenTracing具备更多的优势，从而成为了当前事实上的业界标准