[OpenTelemetry] 現代化監控使用 OpenTelemetry 實現 : OpenTelemetry 開放遙測

前言
最近在 suvery 監控相關議題時接觸到 OpenTelemetry 蒐集遙測數據的開源框架，覺得這議題挺有趣的因此整理變成系列文，這篇是研究 OpenTelemetry 的系列文第二篇， 這系列主要會分為四篇分別是

• 現代化監控使用 OpenTelemetry 實現 : 可觀測性(Observability)
• 現代化監控使用 OpenTelemetry 實現 : OpenTelemetry 開放遙測
• 現代化監控使用 OpenTelemetry 實現 : 在 .NET 如何使用 OpenTelemetry
• 現代化監控使用 OpenTelemetry 實現 : 反思與總結

若對於上述內容有問題或是不清楚的地方，歡迎提出來一起討論

Telemetry
Telemetry 這詞是由兩個單字所組成，分別是 Tele(遠程) 與 Metron(測量)，意思是「遙測」，是指在遠端蒐集測量值或是數據資料，在將其蒐集到的資料自動傳輸到接收端進行監控。在軟體可能過去比較少聽到這詞，但在其他產業項是醫療或是汽車已經是很普及的用語，像是如果今天不舒服住院時，護士可能會在你手上擺放貼片，這些貼片會將身體的資料量是脈搏、血壓等資訊透過病床旁邊的儀器，在送到相同樓層的護理站，當有異常或是心跳部正常時就會透過數據進行遠端監控，確保身體狀況是 OK 沒問題的；在汽車業可能是當車進車廠保養時，維修技師即可透過線插入設備後即可了解車目前的狀況如何，哪邊可能是有意常要注意要修理的。

OpenTelemetry

圖片來源 : CNCF Dev Status

熱門開源框架
從 CNCF (Cloud Native Computing Foundation) 所提供的查詢網頁可以看的到，OpenTelemetry 是 CNCF 中第二個活耀的 Open source 項目(僅次於 K8S)，最近微軟在推的 Dapr 也是使用 OpenTelemetry 作為內建的蒐集數據基礎 ，到底 OpenTelemetry 是什麼 ? 可以在這幾年可以竄升的這麼快，這麼火紅呢 ? 我們先來了解一下過去是怎麼做的以及有哪些解決方案

過去是如何蒐集遙測數據的呢

圖片來源 : Construction and Operation of Observability Platform using Istio
在過去分散式追蹤 (Distributed Tracing) 較著名有 OpenCensus 及 OpenTracing 框架，各自有所定義的規範及實作的內容，透過以上圖可以清楚了解 OpenCensus、OpenTracing 及 OpenTelemetry 之間的關係，在過去 Google 在內部是透過自己開發的 Dapper 系統進行進行分散式追蹤問題確認，在 2016 年提出 OpenCensus 作為分散式追蹤及監控規範標準；同一年 CNCF 提出 OpenTracing 分散式追蹤的標準，提供廠商中立的 API 且在多種程式語言均有實現可以使用。兩種分散式追蹤規範有各自的標準與定義的 API，有各有各的擁護者與愛好者(沒有絕對的好壞)。在 2019 年由多間軟體大廠共同合作下制定了 OpenTelemetry，OpenTelemetry 取代了 OpenCensus 及 OpenTracing 成為新一代的遙測數據蒐集標準。

從官網的介紹摘要如下

 OpenTelemetry 是雲原生(Cloud Native) 的可觀測性(Observability)框架，提供了標準化的 API、SDK 與協議自動檢測、蒐集和導出遙測數據資料(Metric、log、Trace)，支援 W3C 定義的 Http trace-context 規範，降低開發者在蒐集遙測數據上的困難度，方便後續進行分析與了解應用程式的性能與行為，。

OpenTelemetry 是由 CNCF (Cloud Native Computing Foundation) 組織孵化的開源專案，2021/5 通過由 OpenTracing 與 OpenCensus 兩個框架合併，結合兩項分散式追蹤框架重要的特性成為下一代收集遙測數據的新標準，並在 2021/8 月時 OpenTelemetry 進入孵化階段(狀態頁)。

核心元件

在 OpenTelemetry 中核心如下

• API : 開發人員可以透過 OpenTelemetry API 自動生成、蒐集應用程式(Application)的遙測數據資料(Metrics, Log, Trace)，每個程式語言都需實作OpenTelemetry 規範所定義的 API 方法簽章。
• SDK : SDK 是 OpenTelemetry API 的實現
• OTLP : OTLP 規範定義了遙測數據的編碼與客戶端及服務器之間如何交換的協議 (gRPC、HTTP)
• Collector : OpenTelemetry 中儲存庫，用於接收、處理、導出遙測數據到各種後端平台

Context Propagation
OpenTelemetry 其中一個重要的功能為 Context Propagation，甚麼是 Context Propagation 呢 ? 這是在 Trace 中一個相當重要的特性，當今天你的系統架構服務(Service)越切越細時，Client 發出一個請求可能 Response 會由多個資料來源所組成，也藉意味著當今天如果其中一個資料來源緩慢時就可能整個 Response 都會受到影響，透過 Trace 可以得知這多個資料來源是哪一個緩慢所影響，以下圖為例

系統中最小的單位叫做 Span，透過上圖可以得知是由 Span A 資料來源會是 Span B 及 Span C，Span B 資料來源為 Span D，Span C 的來源會是 Span E 與 Span F (G、H 暫省略)，也就意味著 Span C 是 Span E 與 Span F 的上一層。某個請求從進入到回傳整個過程叫做 Trace，那麼我要如何知道 Span A~H 是相關聯的呢 ? 每個 Span 都會有兩個重要的 ID 分別是 SpanId 與 TraceId, SpanID 是每個 Span 各自都會擁有的 ID, TraceID 整串會是相同的 ID 值，這樣在追蹤上就可以透過 TraceID 來將有關聯的 Span 串起來。在上圖所示 Span A~H 這整串的 TraceID 會在相同的，其 ID 值會是 Span A 的 SpanID。
接著再繼續來看，光透過 SpanId 與 TraceId 是沒有辦法得知各自 Span 異常或是緩慢資訊的，在 Span 其實還有蒐集很多相關的內容，以下圖為例這會是 當請求來 SpanB 背後所收集的資訊，可能會把發送到 Server 的 request / response 以及 server 的回應內容，以及所花費的時間記錄下來，才可以透過這些已知已知的訊息找出哪一個服務緩慢，需要服務下線或者是做一些進一步的調整。

Support
OpenTelemetry 是蒐集遠端遙測數據的規範及標準，在目前既有有名的程式語言中都有實作 OpenTelemetry 的開源框架。另外在 Collector 上一些 OpenSource 像是 Grafana 與 Zinkin && Jaeger 現在都支援。詳細要看目前支援什麼 Language、Instrumentation、Exporter 可以到官方網站 Register 自行搜尋。

結論
這篇主要在介紹 OpenTelemetry 的前世今生，解決什麼問題與 Trace 中重要的觀念 Context Propagation，最後在帶到目前支援的程式語言，那麼 OpenTelemetry 規範在 NET 是如何實作的呢 ? 下一篇我將分享在 NET 中如何使用 OpenTelemetry API 以及一些 Demo Code 讓大家可以更容易進入 OpenTelemetry，謝謝

參考
https://opentelemetry.io/