Observability-可觀測性鳥瞰

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

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

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

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

什么是 OpenTelemetry？

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

作為一個CNCF項目，OpenTelemetry 定義了語言中立的規(guī)范，并提供了API、SDK的集合，用于以與供應商無關的方式處理日志、度量和跟蹤等可觀察性數(shù)據(jù)。該項目由兩個競爭項目——OpenTracing 和 OpenCensus 的融合而成，并得到了來自谷歌、微軟、亞馬遜的主要云提供商以及可觀察性領域幾乎所有供應商的支持——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)軟件組件時具有更大的靈活性；無論語言選擇如何，儀器都是一樣的。

2、OpenTelemetry可擴展性架構

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

3、OpenTelemetry 防止供應商鎖定

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

OpenTelemetry 參考架構

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

1、API 和 SDK

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

SDK 也是特定于語言的，提供 API 和導出器之間的橋梁。它可以對跟蹤和聚合指標進行采樣。

2、采集器

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

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

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

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

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

接收器

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

處理器

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

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

導出器

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

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

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

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

OpenTelemetry 如何工作？

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

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

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

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

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

4、轉換和導出數(shù)據(jù)

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

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

關于 OpenTelemetry 的資料庫，詳情可參考如下：

1、OpenTelemetry 的主要組件

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

2、OTel 收集器存儲庫

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

3、OTel 特定于語言的工具

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

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