從宏觀角度來看，OpenTelemetry 是由各種 訊號 (Signals) 所組成的，主要包含 Tracing (追蹤)、Metrics (指標) 和 Logging (日誌)。每一個訊號都是作為獨立的元件進行開發（但仍有方法可以將彼此的資料流串接起來）。

這些訊號都被定義在 OpenTelemetry 的「跨語言規範 (Language-Agnostic Specification)」中，這也是整個專案的核心所在。雖然終端使用者 (End-user) 可能不會直接接觸到這份規範，但它對於確保 OpenTelemetry 生態系中的一致性 (Consistency) 與互通性 (Interoperability) 扮演著至關重要的角色。

OpenTelemetry Specification (Language Agnostic)

這份規範主要由三個部分組成。首先是術語定義，旨在建立共同的詞彙與認知，以避免混淆。其次，它詳述了每個訊號的技術設計細節。這包含：

• API 規範 (請參閱 Tracing API, Metrics API 和 OpenTelemetry Logging)
  • 定義實作 (Implementations) 必須遵守的（概念性）介面。
  • 確保各個實作之間彼此相容。
  • 包含可用於產生、處理及匯出遙測數據 (Telemetry data) 的方法。
• SDK 規範 (請參閱 Tracing SDK, Metrics SDK, Logs SDK)
  • 作為開發人員的指引。
  • 定義特定語言的 API 實作必須滿足哪些需求才能符合標準 (Compliant)。
  • 包含關於遙測數據的設定 (Configuration)、處理和匯出的相關概念。

除了訊號架構之外，該規範也涵蓋了與遙測數據相關的面向。例如，OpenTelemetry 定義了 語意約定 (Semantic Conventions)。透過推動通用遙測 Metadata 在命名與解釋上的一致性，OpenTelemetry 旨在減少對來自不同來源的數據進行「正規化 (Normalize)」的需求。

最後，規範中還包含了 OpenTelemetry Protocol (OTLP)，我們將在本章稍後進行探討。

Generate and Emit Telemetry via the OTel API and SDK Packages

為了從應用程式中產生並發送遙測數據 (Telemetry)，我們使用遵循 OpenTelemetry 規範的「特定語言實作 (Language-specific implementations)」。OpenTelemetry 支援多種熱門的程式語言，且各語言的支援成熟度 (Maturity) 亦有所不同。一個訊號 (Signal) 的實作包含兩個部分：

• API
  • 定義規範中列出的介面 (Interfaces) 與常數。
  • 供應用程式與函式庫開發者使用，以進行供應商中立 (Vendor-agnostic) 的儀表化。
  • 預設指向一個「無操作 (no-op)」的實作（即呼叫後不會執行任何動作）。
• SDK
  • 實作了 OpenTelemetry API 的提供者 (Provider)。
  • 包含產生、處理並發送遙測數據的實際邏輯。
  • OpenTelemetry 隨附了官方提供者作為「參考實作 (Reference Implementation)」（通常直接稱為 SDK）。
  • 您也可以自行撰寫 SDK。

一般來說，我們使用 OpenTelemetry API 將儀表化功能加入原始碼中。實際上，這可以透過多種方式達成，例如：

• 零程式碼 (Zero-code) 或自動儀表化 (Automatic Instrumentation)（若可用，且為了避免修改程式碼）。
• 儀表化函式庫 (Instrumentation Libraries) 提供簡化版 OpenTelemetry 整合的函式庫（可能需要或不需要修改程式碼）。
• 手動或基於程式碼的儀表化 (Manual Instrumentation)（為了精細的控制，並深度嵌入程式碼中）。

目前我們先跳過細節，專注於為何 OpenTelemetry 決定將 API 與 SDK 分離。在啟動時，應用程式會為每種類型的訊號註冊一個提供者 (Provider)。之後，對 API 的呼叫會被轉送 (Forwarded) 給相應的提供者。如果我們沒有明確註冊，OpenTelemetry 將使用一個備援 (Fallback) 提供者，將 API 呼叫轉換為無操作 (no-ops)。

將 API 與 SDK 分離的主要原因，是為了讓開源函式庫更容易嵌入原生儀表化 (Native Instrumentation) 功能。OpenTelemetry 的 API 被設計為輕量級且可安全依賴 (Safe to depend on)。相對地，由 SDK 提供的訊號實作則明顯複雜許多，且很可能包含對其他軟體的依賴 (Dependencies)。若強制使用者接受這些依賴，可能會導致與其特定的軟體環境 (Software stack) 發生衝突。

透過在初始設定期間註冊提供者，允許使用者藉由選擇不同的實作來解決依賴衝突。此外，這讓我們能發布內建可觀測性 (Observability) 的軟體，而不會將儀表化的執行成本 (Runtime cost) 強加給不需要的使用者。

到目前為止，我們已經看到 OpenTelemetry 為應用程式與函式庫開發者提供了供應商中立 (Vendor-agnostic) 的儀表化工具。光是這一點就是一個重大的里程碑，但 OpenTelemetry 框架所涵蓋的範圍不僅止於此。

在產生並發送遙測數據 (Telemetry) 後，維運人員 (Operators) 負責管理這些數據，並將其攝取 (Ingest) 到各自的後端系統中。這包含了以下任務：

• 從各種來源收集數據。
• 解析數據並進行轉換，以供下游處理。
• 使用額外的 Metadata 進行豐富化 (Enrichment)。
• 過濾掉不相關的數據，以減少雜訊並降低儲存需求。
• 進行正規化 (Normalization) 並套用轉換。
• 進行緩衝 (Buffering) 以提升韌性 (Resilience) 與效能。
• 進行路由 (Routing)，將部分遙測數據引導至不同的目的地。
• 轉送至後端系統。

為了建構並設定這類遙測數據管線 (Pipelines)，維運團隊通常會部署額外的基礎設施。一個常見的例子是 fluentbit 遙測代理程式 (Agent)。同樣地，OpenTelemetry 提供了一個具備這些能力的獨立元件：OpenTelemetry Collector。

為了完善標準化、數據產生及管理的整套方案，OpenTelemetry 也定義了如何在生產者 (Producers)、代理程式 (Agents) 和後端 (Backends) 之間傳輸遙測數據。

OpenTelemetry Protocol (OTLP) 是一個開源且供應商中立 (Vendor-neutral) 的傳輸格式 (Wire format)，它定義了：

• 數據如何在記憶體中被編碼。
• 用於在網路上傳輸該數據的協定。

因此，OTLP 被廣泛應用於整個可觀測性堆疊 (Observability stack) 中。以 OTLP 格式發送遙測數據，意味著已儀表化 (Instrumented) 的應用程式與第三方服務，能與無數的可觀測性解決方案相容。

雖然 Collector 支援接收來自各種格式的遙測數據，也能匯出成各種格式（例如：Prometheus Metrics, Zipkin traces 等），但通常會優先選擇 OTLP，因為 Collector 內部正是使用 OTLP 來表示與處理遙測數據。藉此，我們避免了格式轉換的成本，並提升了一致性。這是因為該原生格式與框架提出的理念緊密契合（例如屬性遵循語意約定、跨訊號關聯等）。

同樣地，大多數可觀測性後端都開箱即用 (Right out of the box) 地支援 OTLP。鑑於 OpenTelemetry 的快速普及，整合 OTLP 能讓你自動觸及廣大的潛在使用者群體。此外，一個開源且供應商中立的遙測協定，意味著可觀測性工具開發者的工作量更少。以前，你必須開發無數的轉接器 (Adapters)，才能攝取 (Ingest) 以各種專有格式 (Proprietary formats) 傳來的數據。換句話說，OTLP 大力推動了可觀測性生態系中工具與服務間的互通性 (Interoperability)。

OTLP 提供了三種用於傳輸遙測數據的傳輸機制：HTTP/1.1、HTTP/2 和 gRPC。使用 OTLP 時，傳輸機制的選擇取決於應用程式需求，需考量效能、可靠性與安全性等因素。

OTLP 數據通常使用 Protocol Buffers (Protobuf) 二進位格式進行編碼，該格式精簡且網路傳輸效率高，並支援模式演進 (Schema Evolution)，允許在不破壞相容性的情況下修改未來的資料模型。數據也可以編碼為 JSON 格式，這提供了人類可讀 (Human-readable) 的格式，但缺點是網路流量較高且檔案較大。

在本章中，我們探討了 OpenTelemetry 框架的關鍵元件，涵蓋了它如何提供一種統一的方法來收集與傳輸遙測數據 (Telemetry data)。

我們首先探討了 訊號規範 (Signal Specification)，它是跨語言通用 (Language-agnostic) 的，確保了在不同平台與語言之間，定義和收集遙測數據（Log、Metric、Trace）的一致性。

接著，我們討論了 供應商中立的儀表化 (Vendor-Agnostic Instrumentation)，強調 OpenTelemetry 如何在特定程式語言中實現遙測數據的收集，同時保持獨立性，不被任何特定供應商的可觀測性工具組所綁定。

隨後，我們檢視了 OpenTelemetry Collector 作為遙測數據處理器 (Telemetry Processor) 的角色，詳細說明它如何處理、轉換並匯出遙測數據至各種後端 (Backends)，讓管理可觀測性數據管線 (Pipelines) 更具彈性。

此外，我們介紹了 OTLP (OpenTelemetry Protocol)，它標準化了整個系統中的遙測數據傳輸，確保不同元件之間能有可靠的通訊。

最後，我們提及了 OTel SDK 與 API 規範的重要性，它們定義了開發者如何與 OpenTelemetry 互動；以及 語意約定 (Semantic Conventions)，它為遙測數據提供一致的標籤 (Labeling) 與結構，提升了所收集資訊的清晰度與實用性。

A. 指定使用 OpenTelemetry 的供應商需求 (Vendor requirements)

B. 定義針對特定語言 (Language-specific) 的 Tracing (追蹤) 協定

C. 提供一種一致且跨語言通用 (Language-agnostic) 的遙測數據收集方法

D. 建立自定義訊號以監控網路流量

A. 它確保所有儀表化都在應用程式層級 (Application level) 處理 B. 它支援跨不同程式語言的自動 (Automatic) 與手動 (Manual) 儀表化 C. 它將儀表化僅限於高階效能指標 D. 它提供針對各家雲端供應商 (Cloud Provider) 的預建儀表化功能

A. 用於透過網際網路傳輸遙測數據的預定義格式 B. 僅用於 OpenTelemetry 日誌中的自定義命名慣例 C. 一種透過機器學習演算法處理追蹤 (Traces) 的方法 D. 一套用於一致地組織與標記 (Labeling) 遙測數據的規則