基于OpenTelemetry進(jìn)行全鏈路追蹤

作者：Luga Lee 2023-10-16 23:43:52

云計算

云原生 今天我們來分享一下與云原生體系有關(guān)的話題- 云原生可觀測性-OpenTelemetry。 作為一個云原生“核心”標(biāo)準(zhǔn)，OpenTelemetry在觀測分布式微服務(wù)應(yīng)用程序和云基礎(chǔ)設(shè)施的可見性和控制自動化層面具有舉足輕重的意義。

Observability-可觀測性鳥瞰

正如之前文章所述，可觀測性是根據(jù)對系統(tǒng)產(chǎn)生的外部數(shù)據(jù)（例如日志、指標(biāo)和跟蹤）的了解來獲取系統(tǒng)內(nèi)部發(fā)生的事情的能力。

可觀測性通常通過遙測數(shù)據(jù)來輔助，遙測數(shù)據(jù)可以通過 Dynatrace 以及 OpenTelemetry 等開源項目提供。OpenTelemetry 是一個云原生計算基金會 (CNCF)沙盒項目，其目標(biāo)是提供一組統(tǒng)一的供應(yīng)商不可知庫/API、SDK 和其他工具。它的主要貢獻(xiàn)者之一是 Dynatrace。

基于 OpenTelemetry，IT 團(tuán)隊可以檢測他們的應(yīng)用程序并生成、收集和導(dǎo)出遙測數(shù)據(jù)，以分析和了解軟件架構(gòu)性能和系統(tǒng)行為。

正如 Kubernetes 已成為容器編排的事實標(biāo)準(zhǔn)一樣，OpenTelemetry 現(xiàn)在是為云原生應(yīng)用程序添加可觀測性的事實標(biāo)準(zhǔn)。這意味著公司無需花費寶貴的時間開發(fā)用于收集應(yīng)用程序遙測數(shù)據(jù)的機(jī)制，而是可以專注于他們的主要產(chǎn)品。

什么是 OpenTelemetry？

OpenTelemetry（也稱為 OTel）是一個開源可觀察性框架，由一系列工具、API 和 SDK 組成。Otel 使 IT 團(tuán)隊能夠檢測、生成、收集和導(dǎo)出遙測數(shù)據(jù)以進(jìn)行分析并了解軟件性能和行為。

作為一個CNCF項目，OpenTelemetry 定義了語言中立的規(guī)范，并提供了API、SDK的集合，用于以與供應(yīng)商無關(guān)的方式處理日志、度量和跟蹤等可觀察性數(shù)據(jù)。該項目由兩個競爭項目——OpenTracing 和 OpenCensus 的融合而成，并得到了來自谷歌、微軟、亞馬遜的主要云提供商以及可觀察性領(lǐng)域幾乎所有供應(yīng)商的支持——Splunk、Elastic、Datadog、LightStep、DynaTrace、NewRelic、Logzio、HoneyComb 等。讓我們探索在現(xiàn)有和未來的綠地項目中采用 OpenTelemetry 的好處。

1、OpenTelemetry 規(guī)范的語言中立性允許以不同語言實現(xiàn)

目前，截至本文撰寫時，OpenTelemetry 的 SIG- 特殊興趣組提供了一些最廣泛使用的通用語言的實現(xiàn)：C++，。Net，Java，Javascript，Python，Go，Rust，Erlang，Ruby，PHP，Swift。這些是一組專門的貢獻(xiàn)者，專注于單一語言的實現(xiàn)。如果有一個軟件項目使用目前不受支持的語言，那么將來可能會得到支持。所有這些都意味著在實現(xiàn)軟件組件時具有更大的靈活性；無論語言選擇如何，儀器都是一樣的。

2、OpenTelemetry可擴(kuò)展性架構(gòu)

OpenTelemetry 的可擴(kuò)展架構(gòu)意味著庫/插件作者可以使用 API 儀器化他們的代碼，當(dāng)這些工件在實現(xiàn) OpenTelemetry SDK 的服務(wù)或應(yīng)用程序中使用時，服務(wù)代碼和第三方庫的性能都有可見性。微軟的分布式應(yīng)用程序運(yùn)行時庫就是一個例子。有Spring、Express 等流行框架的插件。

3、OpenTelemetry 防止供應(yīng)商鎖定

OpenTelemetry Collector 允許接收、處理和導(dǎo)出遙測數(shù)據(jù)，支持不同的開源有-Jaeger、Prometheus、Fluent Bit、W3C TraceContext 格式、Zipkin 的 B3 標(biāo)頭等。更重要的是，隨著出口商對不同遙測后端的實施，供應(yīng)商之間的切換變得輕而易舉。例如，人們可以將他們的跟蹤數(shù)據(jù)傳輸?shù)?NewRelic、Elastic、Zipkin 的部署實例等......這都是收集器上的簡單配置更改。將其視為儀器作為一種抽象形式，其中遙測數(shù)據(jù)的目標(biāo)后端從應(yīng)用程序/服務(wù)中抽象出來。

OpenTelemetry 參考架構(gòu)

OpenTelemetry 架構(gòu)圍繞幾個關(guān)鍵組件展開，其中一些組件可以靈活實現(xiàn)。主要組成部分包括：

1、API 和 SDK

OpenTelemetry SDK 是開發(fā)人員用來使用指標(biāo)、跟蹤和日志檢測其應(yīng)用程序的庫。而 OpenTelemetry API 定義了應(yīng)用程序如何相互通信并用于檢測應(yīng)用程序或服務(wù)。它們通常可供開發(fā)人員在流行的編程語言（例如，Ruby、Java、Python）中使用。因為它們是 OpenTelemetry 標(biāo)準(zhǔn)的一部分，所以它們可以與任何 OpenTelemetry 兼容的后端系統(tǒng)一起使用，從而無需在未來重新檢測。

SDK 也是特定于語言的，提供 API 和導(dǎo)出器之間的橋梁。它可以對跟蹤和聚合指標(biāo)進(jìn)行采樣。

2、采集器

OpenTelemetry Collector 是一個可選的中間代理，基于其，可以運(yùn)行它來接收、處理和導(dǎo)出遙測數(shù)據(jù)。應(yīng)用程序通過 OTLP 將遙測數(shù)據(jù)發(fā)送到 OTel 收集器，OTel 收集器在導(dǎo)出到各種可觀察性供應(yīng)商之前執(zhí)行中間處理，例如批處理或速率限制。

需要注意的是：雖然擁有這個中間代理可能會有所幫助，但它確實會為您的堆棧增加一層額外的基礎(chǔ)設(shè)施和復(fù)雜性。

Collector 的工作基本上圍繞處理、過濾、聚合和批量遙測進(jìn)行，為開發(fā)人員提供更大的靈活性來接收、整形和發(fā)送數(shù)據(jù)到多個后端。目前適用于如下兩種主要部署模型：

• 作為應(yīng)用程序內(nèi)或與應(yīng)用程序位于同一主機(jī)中的代理，充當(dāng)主機(jī)的數(shù)據(jù)源（默認(rèn)情況下，OpenTelemetry 假定本地收集器可用）
• 作為接收、導(dǎo)出和處理遙測數(shù)據(jù)的數(shù)據(jù)管道網(wǎng)關(guān)

Collector 由三個組件組成：接收器、處理器和導(dǎo)出器，具體可參考如下所示：

接收器

例如，Jaeger、Prometheus 等，負(fù)責(zé)通過偵聽收集器上特定端口上的調(diào)用來推送或拉取應(yīng)用程序的信號。它們適用于 gRPC 和 HTTP 協(xié)議。可以在 GitHub 上找到特定場景或框架的完整接收器列表。

處理器

處理器位于接收器和輸出器之間；它們使我們能夠在數(shù)據(jù)通過導(dǎo)出器到達(dá)后端之前通過過濾、格式化和豐富數(shù)據(jù)來塑造數(shù)據(jù)。常見用例包括數(shù)據(jù)清理以刪除敏感或私人信息、從跨度中導(dǎo)出指標(biāo)或決定將哪些信號保存到后端。

通常，有許多可用的受支持處理器供使用，當(dāng)然，也可以開發(fā)自己的處理器。它們按順序工作，因此配置順序很重要。盡管處理器不是必需的，但可能會根據(jù)數(shù)據(jù)源推薦一些處理器。

導(dǎo)出器

導(dǎo)出器可以將數(shù)據(jù)推送或拉取到一個或多個配置的后端或目的地（例如，Kafka、OTLP）。其工作方式根據(jù)需要將數(shù)據(jù)轉(zhuǎn)換為不同的格式并將其發(fā)送到定義的端點。導(dǎo)出器在檢測和后端配置之間創(chuàng)建了一個分離層，因此用戶可以在不重新檢測代碼的情況下切換后端。它支持 HTTP 或 gRPC 協(xié)議。流行的導(dǎo)出器包括 Jaeger、Prometheus 和 Zipkin，以及大量其他選項。

3、開放遙測協(xié)議 

OpenTelemetry 協(xié)議 (OTLP) 是 OpenTelemetry 成功的原因之一。它是一種不可知論協(xié)議規(guī)范，定義了數(shù)據(jù)編碼和用于發(fā)送跟蹤、指標(biāo)和日志的傳輸協(xié)議。它可以將數(shù)據(jù)從 SDK 發(fā)送到收集器，然后從收集器發(fā)送到選定的后端。使用 Collector 元素，我們可以通過配置適當(dāng)?shù)慕邮掌鲝牡谌娇蚣苤谐橄蟪鰜怼?/p>

目前，OTLP 使用協(xié)議緩沖區(qū)架構(gòu) (protobuf)，并支持 gRPC 和 HTTP1.1（JSON over HTTP）傳輸。

OpenTelemetry 如何工作？

OTel 是一種專門用于收集遙測數(shù)據(jù)并將其導(dǎo)出到目標(biāo)系統(tǒng)的協(xié)議。由于 CNCF 項目本身是開源的，最終目標(biāo)是使數(shù)據(jù)收集比目前更加系統(tǒng)不可知。但是這些數(shù)據(jù)是如何生成的呢？

數(shù)據(jù)生命周期從開始到結(jié)束有多個步驟。以下是解決方案所采取的步驟，以及它在此過程中生成的數(shù)據(jù)：

1、使用 API 檢測我們所構(gòu)建的代碼，告訴系統(tǒng)組件要收集哪些指標(biāo)以及如何收集它們

2、使用 SDK 匯集數(shù)據(jù)，并將其傳輸以進(jìn)行處理和導(dǎo)出

3、分解數(shù)據(jù)、對其進(jìn)行采樣、過濾以減少噪音或錯誤，并使用多源上下文化對其進(jìn)行豐富

4、轉(zhuǎn)換和導(dǎo)出數(shù)據(jù)

5、在基于時間的批次中進(jìn)行更多過濾，然后將數(shù)據(jù)向前移動到預(yù)定的后端

如上所述，OpenTelemetry 是一個 CNCF 項目?；谑袌龌钴S度以及社區(qū)的推動與發(fā)展綜合評估，目前，OpenTelemetr y項目已是第二活躍的 CNCF 項目，僅次于 Kubernetes。

關(guān)于 OpenTelemetry 的資料庫，詳情可參考如下：

1、OpenTelemetry 的主要組件

• open-telemetry/opentelemetry-specification - OTel 規(guī)范（協(xié)議、度量、跟蹤、日志、行李和根 OTel 的許多其他規(guī)范）、模式和語義約定
• open-telemetry/oteps - 項目的增強(qiáng)建議
• open-telemetry/opentelemetry-proto - OTLP 的 Protobuf 定義

2、OTel 收集器存儲庫

• open-telemetry/opentelemetry-collector - 核心收集器代碼，包括用于自定義收集器發(fā)行版構(gòu)建的ocb工具
• open-telemetry/opentelemetry-collector-contrib - 收集器的 Contrib 接收器、擴(kuò)展、處理器和導(dǎo)出器
• open-telemetry/opentelemetry-collector-releases - 核心和 contrib 發(fā)行版的發(fā)行版不在上述兩個 repos 中，但它們在這里包括發(fā)行發(fā)行版的清單和 Dockerfile
• open-telemetry/opentelemetry-operator - 用于處理收集器的 Kubernetes 操作員，包括用于觀察到的應(yīng)用程序 pod 的收集器邊車注入

3、OTel 特定于語言的工具

• open-telemetry/opentelemetry-go - Go API 和 SDK
• open-telemetry/opentelemetry-go-contrib - OTel Go 的擴(kuò)展，包括儀器和傳播器
• open-telemetry/opentelemetry-python - Python API 和 SDK
• open-telemetry/opentelemetry-python-contrib - OTel Python 的擴(kuò)展

OpenTelemetry 是一個偉大的項目，它提供了一種在我們開發(fā)的軟件中實現(xiàn)高水平可觀察性的方法。通過使用 OTel，我們無需更改任何代碼即可獲得最大的洞察力并回答未來的問題。我強(qiáng)烈建議大家可以深入了解 OpenTelemetry 的精彩世界！如果你愿意，精彩一直會繼續(xù)！

文章題目：基于OpenTelemetry進(jìn)行全鏈路追蹤
文章來源：http://fisionsoft.com.cn/article/dhghsjp.html