前世此生

OpenTracing

OpenTracing 项目启动于 2016 年，旨在供给一套分布式追寻规范，以便开发人员能够更轻松地完成分布式追寻。

OpenTracing 界说了一套 Tracing 模型，以及一套 API，用于在运用程序中创建和办理这些数据模型。

下面是 OpenTracing 的三种彼此相关的核心模型：

1. Span：表明一次调用过程，包括调用的开端和完毕，以及调用过程中的一些信息，比方调用的服务称号、调用的办法称号、调用的参数、调用的返回值、调用的异常等。
2. Tracer：表明一个追寻器，用于创建和办理 Span，并将 Span 发送到追寻体系。
3. SpanContext：表明 Span 的上下文，包括 TraceId、SpanId、Baggage 等信息。

OpenTracing 规则了 Span 上会包括以下信息：

• Operation Name：操作称号，表明 Span 所代表的操作的称号。
• Start Time：开端时刻，表明 Span 的开端时刻。
• Finish Time：完毕时刻，表明 Span 的完毕时刻。
• Tags：标签，表明 Span 的一些标签信息，比方 http.method、http.url、http.status_code 等。
• Logs：日志，表明 Span 的一些日志信息，比方 error、exception 等。
• SpanContext：Span 的上下文，包括 TraceId、SpanId、Baggage 等信息。

Baggage 是 OpenTracing 中的一个概念，跨进程的 Span 之间能够经过 Baggage 传递一些用户自界说的数据，比方用户的 userId、orderId 等。

OpenTracing 还界说了 SpanContext 跨进程传递相关的概念：

Tracer 经过 Inject 和 Extract 办法，将 SpanContext 信息注入到 Carrier 中，以便在跨进程的 Span 之间传递。

• Inject：将 SpanContext 信息注入到 Carrier 中，以便在跨进程的 Span 之间传递。
• Extract：从 Carrier 中提取 SpanContext 信息，以便在跨进程的 Span 之间传递。
• Carrier：载体，表明 SpanContext 信息的载体，比方 HTTP Header、RPC Header 等。

更多完好的 OpenTracing 规范，能够参阅 OpenTracing Specification opentracing.io/specificati… 。

OpenTracing 还供给了一套 SDK用来完成 OpenTracing 规范，github.com/opentracing 。

这套 SDK 只包括数据模型和 API，不包括往后端追寻体系发送数据等功能，需求进一步集成后端追寻体系的 SDK，才能将数据发送到后端追寻体系。

例如，假如要将 Span 发送到 Jaeger，需求进一步集成 Jaeger 的 SDK，将 Span 发送到 Jaeger。

github.com/jaegertraci…

OpenCensus

OpenCensus 是 Google 于 2018年 安排的一个开源项目，相较于 OpenTracing 项目只支撑 Tracing，OpenCensus 项目同时支撑 Tracing 和 Metrics。

OpenTelemetry

OpenTelemetry 是 OpenCensus 和 OpenTracing 项目的兼并，于 2019年 由 CNCF 安排的一个开源项目。除了支撑 Tracing 和 Metrics，还支撑 Logging。

OpenTelemetry 的 Tracing 模型很大程度上继承了 OpenTracing 的 Tracing 模型，所以了解 OpenTracing 的 Tracing 模型，有助于理解 OpenTelemetry 的 Tracing 模型。

OpenTelemetry 项目介绍

OpenTelemetry 简称 OTel，包括三部分：

1. OpenTelemetry Specification：OpenTelemetry 规范，界说了 OTel 的数据模型和 API，还包括规范的数据传输协议 OpenTelemetry Protocol，简称 OTLP。
2. OpenTelemetry SDK：OpenTelemetry SDK，用于完成 OpenTelemetry 规范。
3. OpenTelemetry Collector：一个可插拔的数据搜集器，用于搜集、处理、导出 OTel 的数据。

OpenTelemetry Specification

OpenTelemetry Specification 界说了跨言语的规范，一切言语的 SDK 都需求遵循这个规范。 规范包括以下几个部分：

1. API Specification：API 规范，规则了 OTel 的 API 应该包括哪些办法。
2. SDK Specification：SDK 规范，规则了 OTel 的 SDK 应该应该供给哪些功能。
3. Data Specification：数据规范，界说了 OTel 的数据模型。

详细的规范能够参阅 opentelemetry.io/docs/specs/…

Signals

OpenTelemetry Specification 界说了以下数据模型，这些模型统称为 Signals。

• Tracing
• Metrics
• Logs
• Baggage

上文 OpenTracing 的规划中都有这些概念，这边不再赘述。

Context & Propagation

Context，表明一次调用过程中的上下文，用于在调用过程中传递一些数据，比方 Tracing、Baggage 等。

Propagators（传播器） 利用 Context 为每个横切关注点（例如 Tracing 和 Baggage）注入和提取数据。

通常，Context 会经过 HTTP Header、RPC Header 等方法传递。Propagators 会将 Context 中的数据注入到 HTTP Header、RPC Header 等中，以便在跨进程的调用过程中传递。

OpenTelemetry Protocol

OpenTelemetry Protocol，简称 OTLP，是 OTel 界说的规范的数据传输协议，用于在 OTel 的 SDK 和可观测性后端之间传输数据。 opentelemetry.io/docs/specs/…

OTLP 运用 gRPC 作为传输协议，各个可观测性后端只需求完成 OTLP 的 gRPC 接口，就能够接收 OTel 的数据。

在此之前，各个可观测性后端都有自己的数据传输协议，比方 Jaeger 运用的是 Jaeger Thrift Protocol，Zipkin 运用的是 Zipkin JSON V2 API 等。

OpenTelemetry SDK

OpenTelemetry SDK架构

虚线的上方是 OpenTelemetry API 的界说，下面是详细的 SDK 完成。

Tracing、Metrics、Logging 等数据搜集被称为 Instrumentation，中文资猜中通常叫做埋点。

除了 Instrumentation，还有 Sampler、Processor、Exporter 等组件。

• Sampler：采样器，用于决定数据的采样规则。
• Processor：处理器，用于处理数据，比方将数据聚合、紧缩等。
• Exporter：导出器，用于将数据导出到可观测性后端。经过完成不同的 Exporter，能够将数据导出到不同的后端体系，比方 Jaeger、Zipkin、Prometheus 等。当然也能够经过 OTLP 规范协议将数据导出支撑 OTLP 的后端体系。

OpenTelemetry Collector

Collector 是一个独立的进程，用于搜集、处理、导出 OTel 的数据。

Collector 主要由三个组件组成：

1. Receiver：接收器，用于接收 OTel 的数据，支撑多种数据格式，比方 OTLP、Jaeger Thrift、Zipkin JSON V2 API 等。
2. Processor：处理器，用于处理数据，比方将数据聚合、紧缩等。
3. Exporter：导出器，用于将数据导出到可观测性后端。

Processor 和 Exporter 功能与 OpenTelemetry SDK 中的 Processor 和 Exporter 功能相似，可是 Collector 作为独立的进程，能够会集处理多个运用程序的数据（如经过 OTLP 的 Receiver 进行一致的搜集），而不需求在每个运用程序中都集成 Processor 和 Exporter。

Collector 也是一个可插拔的架构，能够经过装备文件的方法，装备不同的 Processor、Exporter 等组件。

下期预告

下期开端将正式开端介绍如安在 .NET 运用中运用 OpenTelemetry，并在运用过程中，进一步介绍 OpenTelemetry 的规划和完成。