云原生之可观测性-OpenTracing、OpenSensus、OpenTelemetry

一、OpenTracing

官网地址：https://opentracing.io/

OpenTracing是CNCF（Cloud Native Computing Foundation projects）的项目，它是一个与厂商无关的API，并提供了一种规范，可以帮助开发人员轻松的在他们的代码上集成tracing。官方提供了Go, JavaScript, Java, Python, Ruby, PHP, Objective-C, C++, C#等语言的支持。它是开发的不属于任何一家公司。事实上有很多公司正在支持OpenTracing，例如：Zipkin和Jaeger都遵循OpenTracing协议。

2016年11月的时候CNCF技术委员会投票接受OpenTracing作为Hosted项目，这是CNCF的第三个项目，第一个是Kubernetes，第二个是Prometheus，可见CNCF对OpenTracing背后可观察性的重视。

OpenTracing希望围绕什么是Tracing以及如何和我们的应用程序集成形成一种通用语言。OpenTracing中的trace是一个有向无环图，其引用如下：

[Span A]  ←←←(the root span)
            |
     +------+------+
     |             |
 [Span B]      [Span C] ←←←(Span C is a `ChildOf` Span A)
     |             |
 [Span D]      +---+-------+
               |           |
           [Span E]    [Span F] >>> [Span G] >>> [Span H]
                                       ↑
                                       ↑
                                       ↑
                         (Span G `FollowsFrom` Span F)

二、OpenCensus

官网地址：https://opencensus.io/

OpenCensus是Google开源的，作为最早提出Tracing概念的公司，OpenCensus也是Google Dapper的社区版本。

OpenSensus是允许你采集应用程序Metrics和分布式Traces，并且支持各种语言的库，比如：Go, Java, C#, Node.js, C++, Ruby, Erlang/Elixir, Python, Scala and PHP。支持将数据实时传输到后端。开发人员或管理员可以分析这些数据，以了解应用程序的运行状况或调试问题。

读到这里，我们可以很容易分别出OpenTracing和OpenCensus的差别，主要在于OpenCensus把Metrics包括进来了，不仅可以采集traces，还支持采集metrics，还有一点不同OpenCensus并不是单纯的规范制定，他还把包括数据采集的Agent、Collector。

三、OpenCensus VS OpenTracing

1、OpenTracing只支持traces，OpenCensus支持traces和metrics。

2、OpenTracing支持单纯的制定规范，OpenCensus不仅制定规范，还包含了Agent和Collector。

总结：OpenTracing的支持厂商众多，例如：ElasticSearch、Uber、Skywalking、Couchbase。OpenCensus除了有google和微软两大巨头支持，还有Datadog、Jaeger、Zipkin、Prometheus，阵容非常强大。

四、OpenTelemetry

官网地址：https://opentelemetry.io/

OpenTelemetry是CNCF的孵化项目。由OpenTracing和OpenCensus项目合并而成。OpenTelemetry是一组APIs、SDKs、工具和集成，旨在创建和管理遥测数据，如traces、metrics和logs。该项目提供了一个与厂商无关的实现，可以用来将遥测数据发送到你指定的后端，它支持各种流行的开源项目，包括Jaeger和Prometheus。

为什么需要OpenTelemetry及其功能

在微服务，云原生的技术栈中，分布式和多语言体系的架构越来越常见。分布式体系结构带来了各种操作挑战，包括如何快速解决可用性和性能问题。这些挑战导致了必须提高可观测性。

遥测数据为可观测性产品提供动力。传统上，遥测数据由开源项目或商业供应商提供。在缺乏标准化的情况下，最终结果是缺乏数据可移植性，并给用户带来维护的负担。

OpenTelemetry项目通过提供单一的、与厂商无关的解决方案来解决这些问题。该项目得到了云提供商、厂商和最终用户的广泛行业支持和采用。

OpenTelemetry庞大的生态系统由以下几部分组成：

• 跨语言的标准/规范

  定义了跨语言的规范。除术语定义外，还包含：

  • API：定义了tracing、metrics和logging数据的类型和操作。

  • SDK：定义API的特定语言实现需求，这里还定义了配置、数据处理和导出概念。

  • 数据：定义OpenTelemetry Line Protocol （OTLP）和厂商无关的语义约定，后端可以为其提供支持。

• Collector: 采集（collect）、转换（transform）和导出（export）遥测数据的功能

  OpenTelemetry Collector是一个与厂商无关的代理，可以接收、处理和导出遥测数据。它支持以多种格式（例如OTLP、Jaeger、Prometheus以及许多商业/专有工具）接收遥测数据，并将数据发送到一个或多个后端。它还支持在输出遥测数据之前对其进行处理和过滤。Collector contrib软件包支持更多数据格式和后端。

• 各种语言的SDK，包含：C++、.NET、Erlang/Elixir、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift

  OpenTelemetry还包含SDK，SDK是通过使用OpenTelemetry API使用您选择的语言生成遥测数据，并将该数据导出到后端。这些SDK还允许你为公共库或框架增强，一些开源的APM框架会开发很多这样的SDK，例如Skywalking支持多种中间件框架，所以会经常发布SDK。

• 自动增强（Automatic instrumentation）和 contrib packages

  注：Instrumentation大家可以参考Java里面的概念，主要是通过字节码增强的方式实现。例如我们通过增强Springboot，去采集每次Http请求的rt和错误码。

通过如下图，简单理解OpenTelemetry：

OpenTelemetry支持的数据源

1、Metrics

metric是关于一个service的度量（measurement），在运行时捕获。从逻辑上讲，捕获其中一个量度的时刻称为metric event，它不仅包含量度本身，还包括获取它的时间和相关元数据。

应用程序和请求metrics是可用性和性能的重要指标。自定义指标可以深入了解可用性如何影响用户体验和业务。自定义metrics可以深入理解可用性metrics是如何影响用户体验或业务的。

OpenTelemetry目前定义了三个metric工具：

• counter: 一个随时间求和的值，可以理解成汽车的里程表，它只会上升。

• measure: 随时间聚合的值。它表示某个定义范围内的值。

• observer: 捕捉特定时间点的一组当前值，如车辆中的燃油表。

2、Logs

日志是带有时间戳的文本记录，可以是带有元数据结构化（推荐）的，也可以是非结构化的。虽然每个日志都是一个独立的数据源，但它们也可以附加到trace的span中。我们日常使用调用的时候，那个节点出问题了，伴随着也可能看到日志。

在OpenTelemetry中，任何不属于分布式trace或metrics的数据都是日志。例如，event是一种特定类型的日志。日志通常用于确定问题的根本原因，通常包含有关谁更改了内容以及更改结果的信息。

3、Traces

trarce是指单个请求的追踪，请求可以由应用程序发起，也可以由用户发起。例如：订单应用通过RPC服务器访问商品库存应用，或是用户在浏览器端执行一次下单请求。分布式tracing是一种跨网络，跨应用程序的追踪形式。每个工作单元在trace中被称为span，一个trace由一个树形的 span 组成。span表示经过应用程序所设计的服务或组件所做工作的对象，span还提供了可用于调试可用性和性能问题的请求、错误和持续时间的metrics。span包含了一个span上下文，它是一组全局唯一标识符，表示每个span所属的唯一请求。通常我们称之为trace id。

4、Baggage

除了 trace 的传播，OpenTelemetry 还提供了 Baggage 来传播键值对。Baggage 用于索引一个服务中的可观察事件，该服务包含同一事务中先前的服务提供的属性，有助于在事件之间建立因果关系。

虽然 Baggage 可以用作其他横切关注点的原型，但这种机制主要是为了传递 OpenTelemetry 可观测性系统的值。

这些值可以从 Baggage 中消费，并作为度量的附加维度，或日志和跟踪的附加上下文使用。一些例子:

• web 服务可以从包含发送请求的服务的上下文中获益

• SaaS 提供商可以包含有关负责该请求的 API 用户或令牌的上下文

• 确定特定浏览器版本与图像处理服务中的故障相关联

w3c baggage : https://w3c.github.io/baggage/

OpenTelemetry不是什么？

OpenTelemetry不是像Jaeger、Skywalking、Prometheus这框架具备存储，查询，dashboard的服务。相反，它支持将数据导出到各种开源和商业后端。它提供了一个可插拔的体系结构，因此可以轻松添加附加的技术协议和格式。

五、什么是遥测数据

遥测数据是通过传感器被遥测终端接收到的实时数据。来自遥测对象，反映遥测对象的数字特征或状态，可作为科研和决策分析的数据依据。

以上是百度百科对遥测数据的说明，对于可观测领域，我们可以理解成遥测数据是从可观测端采集上来的数据，例如：浏览器对DOM的运行数据、服务器端CPU、IO等数据、网络数据、应用程序中公共库和中间件的运行数据。

六、总结

OpenTelemetry定义了数据标准，同时支持了采集和传输，这类公司是相当繁重的。我们平常一个项目使用到的公共库和开源框架可能就有十几种，还可能存在版本的差异，而且项目和项目的语言可能还不一样，如果要对多语言，多开源框架进行遥测数据的采集，工作量之大可想而知。

如果考虑做监控系统，可以考虑使用OpenTelemetry，可以帮助我们省去这些繁琐的数据采集的开发，将精力集中在数据的分析、存储和产品化上。让APM产品更易用，而从提高开发和运维对系统可观测性的需求。

参考文档：

https://opentelemetry.io/

https://www.bmc.com/blogs/opentracing-opencensus-openmetrics/

往期阅读

Lombok我们真的不应该使用了嘛？

大厂“断子绝孙式”、“养蛊式”招聘有多害人？

云原生之可观测性 - APM概念及选型

Kafka Producer全流程分析和思考

MySQL的Replace用法详解

卷不动了，我选择降薪去外企来平衡工作和生活

HBase、Cassandra、LevelDB、RocksDB 相关数据结构是什么？

从Log4j2原理、攻击和解决方案来聊聊全球性的Log4j2漏洞

2022大厂开始反内卷，阿里和蚂蚁升级员工福利，打响第一枪

快乐程序员、读书狂魔、爱撸代码、开源项目、硬核互联网技术分享

觉得写得不错，请点在看，谢谢！