OpenTelemetry 簡介

OpenTelemetry 可以用於從應用程序收集數據。它是一組工具、API 和 SDK 集合，我們可以使用它們來檢測、生成、收集和導出遙測數據（指標、日誌和鏈路追蹤），以幫助分析應用的性能和行爲。

爲什麼需要分佈式追蹤

隨着雲計算、微服務架構和日益複雜的業務需求的興起，越來越需要對軟件和基礎設施可觀測性的需求。特別是在微服務架構中，每個請求最終可能會經過數個甚至數十個微服務）並在其間進行多次網絡調用。

參照下圖 Uber 2018 年的微服務架構，該架構擁有 3000 多個服務。

Uber’s microservice architecture circa mid-2018 from Jaeger

在這種複雜的系統中，僅靠傳統的日誌和指標監控數據很難實現一覽全局的視角，排除故障會非常困難。

• 指標：在監控 / 指標平臺中，組件（例如服務、主機）是被觀察的基本單元。我們可以通過監控 / 指標平臺查詢有關該單元隨着時間推移的實際情況。例如，該服務在特定時間範圍內的運行狀況 / 吞吐量 / 錯誤率是多少？

• 日誌：對於日誌，被觀察的基本單位是_事件_——例如，每當代碼執行期間發生事件時，就打印一些信息。這些 “事件” 是開發人員在編寫代碼時主觀定義的。使用日誌的問題在於它們之間都是相互脫節的，每個組件都以自己的形式單獨打印日誌消息，沒有簡單的方法將它們聯繫在一起，使其更有意義。

相比之下，分佈式鏈路追蹤觀察的是單個_請求_穿越多個組件時的情況。這使我們能夠順着請求鏈路查詢整個分佈式系統的問題，並瞭解複雜的互連繫統中發生了什麼。

why need tracing

藉助分佈式鏈路追蹤能夠幫助我們在複雜的分佈式系統中快速定位問題、排除故障。

OpenTelemetry 演進歷史

OpenTelemetry History

• Google 2010 年發佈的 Dapper 論文是分佈式鏈路追蹤的開端

• 2012 年 Twitter 開源了 Zipkin。

• 2015 年 Uber 發佈了 Jaeger 的開源版本。目前 Zipkin 和 Jaeger 仍然是最流行的分佈式鏈路追蹤工具之一。

• 2015 年 OpenTracing 項目被 CNCF 接受爲它的第三個託管項目，致力於標準化跨組件的分佈式鏈路追蹤。

• 2017 年 Google 將內部的 Census 項目開源，隨後 OpenCensus 在社區中流行起來。

• 2019 年初，兩個現有開源項目：OpenTracing 和 OpenCensus 被宣佈合併爲 OpenTelemetry 項目。

• 2021 年， OpenTelemetry 發佈了 V1.0.0，爲客戶端的鏈路追蹤部分提供了穩定性保證。

• 2023 年對於 OpenTelemetry 來說是一個里程碑，因爲其三個基本信號，鏈路追蹤、指標和日誌，都達到了穩定版本。

如何實現分佈式鏈路追蹤

把請求鏈路中進行的每個網絡調用都會被捕獲並表示爲一個跨度。

分佈式鏈路追蹤工具將唯一的鏈路追蹤上下文（trace ID）插入到每個請求的標頭中，並藉助各種實現工具確保鏈路追蹤上下文在整個請求鏈路中傳播。

OTel TraceID

什麼是 OpenTelemetry

對於 OpenTelemetry，不同的角色（Dev 和 Ops）側重點也不盡相同。

如果你的角色是 Dev，那麼你可能更關注如何通過編寫代碼使程序獲得可觀測性。

如果你的角色是 Ops，那麼你可能更關注如何從多個服務中收集 traces、metrics 和 logs 數據，並將它們發送到可觀測後臺。

OpenTelemetry，也稱爲 OTel，是一個與供應商無關的開源可觀測性框架，用於檢測、生成、收集和導出遙測數據，如鏈路追蹤（traces）、指標（metrics）和日誌（logs）。

作爲一個行業標準，OpenTelemetry 得到了 40 多個可觀測性供應商的支持，被許多 庫、服務和應用程序集成，並被衆多終端用戶採用。

OTel 圖解

相關概念

信號

OpenTelemetry 的目的是收集、處理和輸出信號。信號是用於描述操作系統和平臺上運行的應用程序基本活動的系統輸出。信號可以是你想在特定時間點測量的東西，如溫度或內存使用率，也可以是你想追蹤的分佈式系統組件中發生的事件。你可以將不同的信號組合在一起，從不同角度觀察同一項技術的內部運作。

OpenTelemetry 目前支持 traces、metrics、logs 和 baggage。

• trace：在分佈式應用程序中的完整請求鏈路信息。

• 指標是在運行時捕獲的服務指標，應用程序和請求指標是可用性和性能的重要指標。

• 日誌是系統或應用程序在特定時間點發生的事件的文本記錄。

• baggage：是在信號之間傳遞的上下文信息。

關於 Tracing、Metrics 和 Logging 之間的關係。

Tracing-Metrics-Logging

日誌系統，指標系統，追蹤系統這三個關注的重點不一樣、佔用的磁盤資源也不一樣。

OTLP

開放遙測協議（OTLP）規範描述了遙測源、中間節點（如採集器和遙測後端）之間的遙測數據編碼、傳輸和交付機制。

OTLP 是在 OpenTelemetry 項目範圍內設計的通用遙測數據傳輸協議。

Collector

OpenTelemetry Collector 提供了一種與供應商無關的接收、處理和導出遙測數據的方式。它無需運行、操作和維護多個代理 / 收集器。它具有更好的可擴展性，支持向一個或多個開源或商業後端發送開源可觀測性數據格式（如 Jaeger、Prometheus、Fluent Bit 等）。本地收集器代理是儀器庫導出遙測數據的默認位置。

OTel Collector

可觀測後臺

Jaeger 和 Zipkin 是社區中比較流行的方案，他們都提供有可視化的 WebUI 方便查詢。

下圖是 Jaeger UI 界面。

Jaeger UI

更多

Apache SkyWalking 是一個開源的應用程序性能監控解決方案，用於分佈式系統的應用程序性能監視工具，特別是爲微服務、雲原生和基於容器 (Kubernetes) 架構設計的，提供鏈路追蹤、指標聚合、報警和可視化。

參考資料

https://segmentfault.com/a/1190000041700848

https://hackernoon.com/distributed-tracing-past-present-and-future

https://tracetest.io/blog/tracing-the-history-of-distributed-tracing-opentelemetry

https://cloudnative.to/blog/why-the-latest-advances-in-opentelemetry-are-significant/

https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

https://opentelemetry.io/docs/

https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

https://grafana.com/blog/2023/12/18/opentelemetry-best-practices-a-users-guide-to-getting-started-with-opentelemetry/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wZCpDaMZb92MYqcaLbdd7Q