初探 OpenTelemetry

为什麽会接触到 OpenTelemetry，算是因为 Log 的追踪关系，在後台上有两三个 Spring boot 服务，因为在测试时可能因为一些原因导致错误出现，这时我们就要爬 Log 慢慢追踪，但 Log 并没有上下关系因此在追踪上相对麻烦。也因为我刚入职不久，加上先前我参与了 Cloud Native Taiwan 的议程，刚好有人分享 Dapper 的原理，因此我提出分散式链路追踪的想法。所以有极短时间在研究分散式链路追踪刚好 OpenTelemetry 的规范也刚出不久也尝试玩玩它。

官方说 OpenTelemetry is a collection of tools, APIs, and SDKs. You can use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) for analysis in order to understand your software's performance and behavior.

OpenTelemetry 是为了方便分析软件性能与行为。

其支持的语言有

• JAVA
• C#
• Go
• javascript
• 等
  支持的组件
• MySQL
• Redis
• Django
• Grpc
• Kafka
• Jetty
• Akka
• RabbitMQ
• Spring
• Flask
• net/http
• gorilla/mux
• WSG
• JDBC
• PostgreSQL

其第一个稳定版本於 2021/02 发布，预计下半年完成 Metric 部分。

Opentelemtry 组件

• proto
  • 定义数据
• Specification
  • 有 API、SDK、Data
  • API: 用於生成数据。为每个数据源以及其他方面像是 baggage 和 propagators 定义。
  • SDK: 具有处理和导出功能的 API 实现。为每个数据源以及其他方面像是资源和配置定义。
  • 定义语义约定以提供与供应商无关的实现以及 OpenTelemetry 协议（OTLP）。
• Collector
  • 接收、处里和导出数据
  • 支援发送到一个或多个开源或商业後端的开源可观察性数据格式，例如 Jaeger、Prometheus 等
• Instrumentation Libraries
  • 蒐集不同组件的数据

API

可将 API 分成以下

1. A Tracer API
2. A Metrics API
3. A Context API
4. A set of semantic conventions

Trace

Trace API 会产生 Span，而 Span 会是该 Trace 中所做的操作，表示 Trace 中连续的操作。在 Span 中会给予一个 traceId，当中可为带有时间戳的事件进行其它讯息的添加。
trace 代表了一个在系统中执行的过程。在 OpenTelemetry 标准下，trace 是一个有向无环图（DAG）由多个 span 组成，每个 span 代表着 trace 中被命名和计时的连续性执行片段，Span 之间交互的边被定义为父/子关系。

一个 tracer 过程中，每个 span 关系


        [Span A]  ←←←(the root span)
            |
     +------+------+
     |             |
 [Span B]      [Span C] ←←←(Span C 是 Span A 的子节点, ChildOf)
     |             |
 [Span D]      +---+-------+
               |           |
           [Span E]    [Span F] >>> [Span G] >>> [Span H]
                                       ↑
                                       ↑
                                       ↑
                         (Span G 在 Span F 後被调用, FollowsFrom)

时间轴的呈现

上面 tracer 与 span 时间轴关系

––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time

 [Span A···················································]
   [Span B··············································]
      [Span D··········································]
    [Span C········································]
         [Span E·······]        [Span F··] [Span G··] [Span H··]

Metric

Metric API 提供各式各样类型的度量存取，像是 Counters、Observers。可在 Span 上下文中观察当前 CPU 负载和 Disk 资讯等。可参考官方的资讯

Context

添加上下文的讯息，像是 W3C Trace Context, Zipkin B3 headers等。此外，此 API 允许追踪 Span 如何在系统中传播。随着trace 从一个行程传播到下一个行程，上下文也会更新。度量工具不论何时都可以访问当前上下文。

Semantic conventions

在 OpenTelemetry API 中包含一组语义约定，当中包含了命名 Span、属性以及错误关联至 Span 的准则和规则。藉由在API 规范中对此进行编程，OpenTelemetry 可确保所有工具（无论作者或语言）都包含相同的语义讯息。

SDK

OpenTelemetry SDK 是 OpenTelemetry API 的实现。基本上由三个组件组成

• a Tracer
• a Meter
• and a shared Context layer that ties it all together

原则上 SDK 能够满足现有的需求，但这可以进行改动。

Collector

Receivers 会是数据的入口，它是 push 和 pull 模式，客户端可以发送数据，或是以主动方式拉取数据。
Exporters 是出口，将数据丢至後端，同时也是 push 和 pull 模式
Processors 是一个管道的设置，是一个中间组间，可运行数据的处里
Extensions 是其它的组件

Opentelemtry 架构

左边和右边是不一样的布署方式。

不过 Opentelemtry 因为尚未完全的成熟，因此只有针对 Trace 部分进行研究，明天会带上 Jaeger 基本的构建和使用来玩玩 Trace，不过 Trace 对除错的帮助满大的因为它实现了上下文的关系在搭配日志可以更有效率。

参考资源

• https://github.com/open-telemetry/opentelemetry-specification
• https://blog.newrelic.com/