前世今生

OpenTracing

OpenTracing 專案啟動於 2016 年，旨在提供一套分散式追蹤標準，以便開發人員可以更輕鬆地實現分散式追蹤。

OpenTracing 定義了一套 Tracing 模型，以及一套 API，用於在應用程式中建立和管理這些資料模型。

下面是 OpenTracing 的三種相互關聯的核心模型：

Span：表示一次呼叫過程，包括呼叫的起始和結束，以及呼叫過程中的一些資訊，比如呼叫的服務名稱、呼叫的方法名稱、呼叫的引數、呼叫的返回值、呼叫的異常等。
Tracer：表示一個追蹤器，用於建立和管理 Span，並將 Span 傳送到追蹤系統。
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 https://opentracing.io/specification/ 。

OpenTracing 還提供了一套 SDK用來實現 OpenTracing 規範，https://github.com/opentracing 。

這套 SDK 只包含資料模型和 API，不包含往後端追蹤系統傳送資料等功能，需要進一步整合後端追蹤系統的 SDK，才能將資料傳送到後端追蹤系統。

例如，如果要將 Span 傳送到 Jaeger，需要進一步整合 Jaeger 的 SDK，將 Span 傳送到 Jaeger。

https://github.com/jaegertracing/jaeger-client-csharp/tree/master

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，包含三部分：

OpenTelemetry Specification：OpenTelemetry 規範，定義了 OTel 的資料模型和 API，還包括標準的資料傳輸協定 OpenTelemetry Protocol，簡稱 OTLP。
OpenTelemetry SDK：OpenTelemetry SDK，用於實現 OpenTelemetry 規範。
OpenTelemetry Collector：一個可插拔的資料收集器，用於收集、處理、匯出 OTel 的資料。

OpenTelemetry Specification

OpenTelemetry Specification 定義了跨語言的規範，所有語言的 SDK 都需要遵循這個規範。
規範包括以下幾個部分：

API Specification：API 規範，規定了 OTel 的 API 應該包含哪些方法。
SDK Specification：SDK 規範，規定了 OTel 的 SDK 應該應該提供哪些功能。
Data Specification：資料規範，定義了 OTel 的資料模型。

詳細的規範可以參考 https://opentelemetry.io/docs/specs/otel/

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 和可觀測性後端之間傳輸資料。
https://opentelemetry.io/docs/specs/otlp/

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 主要由三個元件組成：

Receiver：接收器，用於接收 OTel 的資料，支援多種資料格式，比如 OTLP、Jaeger Thrift、Zipkin JSON V2 API 等。
Processor：處理器，用於處理資料，比如將資料聚合、壓縮等。
Exporter：匯出器，用於將資料匯出到可觀測性後端。

Processor 和 Exporter 功能與 OpenTelemetry SDK 中的 Processor 和 Exporter 功能類似，但是 Collector 作為獨立的程序，可以集中處理多個應用程式的資料（如通過 OTLP 的 Receiver 進行統一的收集），而不需要在每個應用程式中都整合 Processor 和 Exporter。

Collector 也是一個可插拔的架構，可以通過組態檔的方式，設定不同的 Processor、Exporter 等元件。

下期預告

下期開始將正式開始介紹如何在 .NET 應用中使用 OpenTelemetry，並在使用過程中，進一步介紹 OpenTelemetry 的設計和實現。

使用 OpenTelemetry 構建 .NET 應用可觀測性（2）：OpenTelemetry 專案簡介