毫無(wú)疑問(wèn)，在過(guò)去幾年里，你可能已經(jīng)多次聽(tīng)到過(guò)可觀測(cè)性這個(gè)詞。對(duì)于很多人來(lái)說(shuō)，很難理解這個(gè)詞的真正含義。對(duì)許多人來(lái)說(shuō)，他們錯(cuò)誤地將其等同于 "監(jiān)控"。雖然可觀測(cè)性的根本定義以及它所包含的一切都不在本系列博文的討論范圍之內(nèi)，但我強(qiáng)烈建議您購(gòu)買一本由 Charity Majors (twitter)、Liz Fong-Jones (twitter) 和 George Miranda (twitter) 合著的《可觀測(cè)性工程》（Observability Engineering）（https://www.oreilly.com/library/view/observability-engineering/9781492076438/?）一書。

不過(guò)，本系列博文將介紹使用 OpenTelemetry 實(shí)現(xiàn)可觀測(cè)性的完整示例和說(shuō)明，OpenTelemetry 是 CNCF 的一個(gè)項(xiàng)目，致力于讓可觀測(cè)性變得更簡(jiǎn)單。

什么是 OpenTelemetry？

OpenTelemetry 是幾年前 OpenCensus 和 OpenTracing 合并的產(chǎn)物。從那時(shí)起，OpenTelemetry（也簡(jiǎn)稱為 "OTel"）就很好地將自己定位為在現(xiàn)代軟件世界中獲取遙測(cè)數(shù)據(jù)且廠商中立的方法。很多人會(huì)說(shuō) OpenTelemetry 是可觀測(cè)性的未來(lái)，根據(jù)我的經(jīng)驗(yàn)和接觸，我傾向于同意這種說(shuō)法。

OTel 組件

在 OpenTelemetry 中典型的 OTel 方案可以被細(xì)分為幾個(gè)邏輯組件，他們包括 APIs,?SDKs, 收集器.

APIs and SDKs

在開(kāi)始使用 OpenTelemetry 時(shí)，首先要了解的重要事項(xiàng)之一是該項(xiàng)目如何區(qū)分 API 和 SDK。簡(jiǎn)而言之，API 負(fù)責(zé)收集遙測(cè)數(shù)據(jù)及其中的所有數(shù)據(jù)，而 SDK 則負(fù)責(zé)將這些數(shù)據(jù)從當(dāng)前被觀測(cè)的進(jìn)程中提取出來(lái)，轉(zhuǎn)給另一個(gè)實(shí)體進(jìn)行分析。隨著我們對(duì)這個(gè)示例的深入研究，這一點(diǎn)將變得更有意義，但值得理解的是 API 和 SDK 之間的職責(zé)分離。

由于它們是關(guān)注點(diǎn)分離的，通過(guò)什么是觀測(cè)（API）與如何處理（SDK）來(lái)區(qū)分它們。它們支持多種編程語(yǔ)言，包括（但不限于）：Go、Python、Java、Ruby、JavaScript、.NET 等！有關(guān)語(yǔ)言支持的更多信息，請(qǐng)查看埋點(diǎn)文檔（?https://opentelemetry.io/docs/instrumentation/ ）。我們將在稍后的博文中介紹埋點(diǎn)知識(shí)。

Collector

SDK 的職責(zé)之一就是從正在被觀測(cè)的進(jìn)程中獲取數(shù)據(jù)，但是需要一個(gè)地方來(lái)匯總接收這些數(shù)據(jù)。我們將這個(gè)獨(dú)立的進(jìn)程稱為收集器。

收集器的整個(gè)工作可分為三個(gè)不同階段：

• 接收遙測(cè)數(shù)據(jù)

• 處理遙測(cè)數(shù)據(jù)

• 導(dǎo)出遙測(cè)數(shù)據(jù)

收集器是一個(gè)處理遙測(cè)數(shù)據(jù)的 ETL（Extract, Transform, Load）管道。雖然不一定要使用 OTel 解決方案，不過(guò)想要找個(gè)一個(gè)常用且好用的收集器例子，推薦用?OpenTelemetry Collector（ https://opentelemetry.io/docs/collector/?），它將是本系列的重點(diǎn)，并將在后面的博文中詳細(xì)介紹。

Traces, metrics, and logs

在鏈路追蹤和可觀測(cè)性中，有三方面信息：鏈路追蹤，指標(biāo)數(shù)據(jù)和服務(wù)日志。雖然我們長(zhǎng)期以來(lái)一直使用服務(wù)日志和指標(biāo)數(shù)據(jù)，但是許多人認(rèn)為鏈路追蹤才是真正解鎖可觀測(cè)性能力的關(guān)鍵。

通過(guò)收集具備高基數(shù)（基數(shù)是指某個(gè)屬性或維度的唯一值的數(shù)量，高基數(shù)數(shù)據(jù)可以認(rèn)為是提供更全面和詳盡的上下文信息）特點(diǎn)的鏈路追蹤數(shù)據(jù)，我們就具備了不用修改代碼也能夠快速解答部分問(wèn)題的能力。分析數(shù)據(jù)是可以有多種手段，例如說(shuō)我們可以對(duì)比異常數(shù)據(jù)和常規(guī)數(shù)據(jù)等。

本系列博文將會(huì)專注于講解鏈路追蹤，如果你想進(jìn)一步了解可觀測(cè)性，以及三種信息之間差異可以參閱前文提到的《可觀測(cè)性工程》一書。

示例應(yīng)用

本系列博文的主要任務(wù)是介紹如何使用 OpenTelemetry 來(lái)讓軟件系統(tǒng)具備可觀測(cè)性。為此，我創(chuàng)建了一個(gè)示例應(yīng)用程序，并在后續(xù)文章中說(shuō)明在應(yīng)用過(guò)程中的一些要點(diǎn)。該應(yīng)用程序的設(shè)計(jì)可參見(jiàn)下圖：

這是一個(gè)購(gòu)物車應(yīng)用程序示例，按功能模塊分成了不同的 web 服務(wù)：

• 購(gòu)物車 - 處理用戶購(gòu)物車數(shù)據(jù)請(qǐng)求的服務(wù)（用 Go 語(yǔ)言編寫）

• 用戶服務(wù) - 處理來(lái)自購(gòu)物車服務(wù)的用戶驗(yàn)證和查詢請(qǐng)求（用 Go 語(yǔ)言編寫）

• 定價(jià)服務(wù) - 為產(chǎn)品提供更新定價(jià)信息服務(wù)（用 Python 編寫）

后端依賴 MySQL 對(duì)數(shù)據(jù)進(jìn)行持久化存儲(chǔ)。

使用 OpenTelemetry 的 API 和 SDK 進(jìn)行埋點(diǎn)。遙測(cè)數(shù)據(jù)是通過(guò) OpenTelemetry Collector 向 Jaeger 發(fā)送數(shù)據(jù)來(lái)實(shí)現(xiàn)的。

下面是使用 OpenTelemetry 采集并展示分布式鏈路跟蹤數(shù)據(jù)在 Jaeger 中的示例：

所有代碼和構(gòu)建運(yùn)行說(shuō)明都可以在 GitHub 上找到：trstringer/otel-shopping-cart。

總結(jié)

希望通過(guò)上面介紹讓您現(xiàn)在對(duì) OpenTelemetry 已經(jīng)有所了解，知道它由哪些組件構(gòu)成，以及我們將如何在本系列的其余部分深入實(shí)施。這僅僅是個(gè)開(kāi)始！請(qǐng)繼續(xù)關(guān)注本系列博文的其余部分，了解如何使用 OpenTelemetry 來(lái)讓應(yīng)用程序具備可觀測(cè)性。

本文翻譯自：https://trstringer.com/otel-part1-intro/

擴(kuò)展閱讀：

• 方法論：面向故障處理的可觀測(cè)性體系建設(shè) （ https://flashcat.cloud/blog/construction-of-observability-system-for-fault-processing/?）

• 好工具：FlashDuty - 一站式告警處理平臺(tái)：告警降噪、排班 OnCall（ https://flashcat.cloud/product/flashduty/?）