這方面要跟進(jìn)新動(dòng)向

https://jimmysong.io/docs/opentelemetry-obervability/history/

第 1 章：可觀測(cè)性的歷史

可觀測(cè)性行業(yè)正處在巨變中。

傳統(tǒng)上，我們觀察系統(tǒng)時(shí)使用的是一套筒倉式的、獨(dú)立的工具，其中大部分包含結(jié)構(gòu)不良（或完全非結(jié)構(gòu)化）的數(shù)據(jù)。這些獨(dú)立的工具也是垂直整合的。工具、協(xié)議和數(shù)據(jù)格式都屬于一個(gè)特定的后端或服務(wù)，不能互換。這意味著更換或采用新的工具需要耗費(fèi)時(shí)間來更換整個(gè)工具鏈，而不僅僅是更換后端。

這種孤立的技術(shù)格局通常被稱為可觀測(cè)性的 “三大支柱”：日志、度量和（幾乎沒有）追蹤（見圖 1-1）。

日志

記錄構(gòu)成事務(wù)的各個(gè)事件。

度量

記錄構(gòu)成一個(gè)事務(wù)的事件的集合。

追蹤

測(cè)量操作的延遲和識(shí)別事務(wù)中的性能瓶頸，或者類似的東西。傳統(tǒng)上，許多組織并不使用分布式追蹤，許多開發(fā)人員也不熟悉它。

[圖片上傳失敗...(image-3bd938-1652921820395)]

<figcaption style="box-sizing: border-box; display: block; margin-top: 0.75em; margin-bottom: 1.65rem; line-height: 1.4; font-size: 0.76rem; text-align: center;">圖 1-1：可觀測(cè)性的 “三大支柱”。</figcaption>

我們用這種方法工作了很久，以致于我們不常質(zhì)疑它。但正如我們將看到的，“三大支柱” 并不是一種正確的結(jié)構(gòu)化的可觀測(cè)性方法。事實(shí)上，這個(gè)術(shù)語只是描述了某些技術(shù)碰巧被實(shí)現(xiàn)的方式，它掩蓋了關(guān)于如何實(shí)際使用我們的工具的幾個(gè)基本事實(shí)。

什么是事務(wù)和資源？

在我們深入探討不同可觀測(cè)性范式的利弊之前，重要的是要定義我們所觀察的是什么。我們最感興趣的分布式系統(tǒng)是基于互聯(lián)網(wǎng)的服務(wù)。這些系統(tǒng)可以被分解成兩個(gè)基本組成部分：[事務(wù)和資源]。

事務(wù)（transaction）代表了分布式系統(tǒng)需要執(zhí)行的所有動(dòng)作，以便服務(wù)能夠做一些有用的事情。加載一個(gè)網(wǎng)頁，購買一個(gè)裝滿物品的購物車，訂購一個(gè)共享汽車：這些都是事務(wù)的例子。重要的是要理解，事務(wù)不僅僅是數(shù)據(jù)庫事務(wù)。對(duì)每個(gè)服務(wù)的每個(gè)請(qǐng)求都是事務(wù)的一部分。

例如，一個(gè)事務(wù)可能從一個(gè)瀏覽器客戶端向一個(gè)網(wǎng)絡(luò)代理發(fā)出 HTTP 請(qǐng)求開始。代理首先向認(rèn)證系統(tǒng)發(fā)出請(qǐng)求以驗(yàn)證用戶，然后將請(qǐng)求轉(zhuǎn)發(fā)給前端應(yīng)用服務(wù)器。應(yīng)用服務(wù)器向各種數(shù)據(jù)庫和后端系統(tǒng)發(fā)出若干請(qǐng)求。例如，一個(gè)消息系統(tǒng)：Kafka 或 AMQP，被用來排隊(duì)等待異步處理的額外工作。所有這些工作都必須正確完成，以便向急切等待的用戶提供結(jié)果。如果任何部分失敗或耗時(shí)過長，其結(jié)果就是糟糕的體驗(yàn)，所以我們需要全面理解事務(wù)。

一路下來，所有這些事務(wù)都在消耗資源（resource）。網(wǎng)絡(luò)服務(wù)只能處理這么多的并發(fā)請(qǐng)求，然后它們的性能就會(huì)下降并開始失效。這些服務(wù)可以擴(kuò)大規(guī)模，但它們與可能調(diào)用鎖的數(shù)據(jù)庫互動(dòng)，造成瓶頸。數(shù)據(jù)庫讀取記錄的請(qǐng)求可能會(huì)阻礙更新該記錄的請(qǐng)求，反之亦然。此外，所有這些資源都是要花錢的，在每個(gè)月的月底，你的基礎(chǔ)設(shè)施供應(yīng)商會(huì)給你發(fā)賬單。你消耗的越多，你的賬單就越長。

如何解決某個(gè)問題或提高服務(wù)質(zhì)量？要么是開發(fā)人員修改事務(wù)，要么是運(yùn)維人員修改可用資源。就這樣了。這就是它的全部內(nèi)容。當(dāng)然，魔鬼就在細(xì)節(jié)中。

第四章將詳細(xì)介紹可觀測(cè)性工具表示事務(wù)和資源的理想方式。但是，讓我們回到描述迄今為止我們一直在做的非理想的方式。

不是所有事情都是事務(wù)

請(qǐng)注意，除了跨事務(wù)之外，還有其他的計(jì)算模型。例如，桌面和移動(dòng)應(yīng)用程序通常是基于反應(yīng)器（reactor）模型，用戶在很長一段時(shí)間內(nèi)連續(xù)互動(dòng)。照片編輯和視頻游戲就是很好的例子，這些應(yīng)用有很長的用戶會(huì)話，很難描述為離散的事務(wù)。在這些情況下，基于事件的可觀測(cè)性工具，如真實(shí)用戶監(jiān)控（RUM），可以增強(qiáng)分布式追蹤，以更好地描述這些長期運(yùn)行的用戶會(huì)話。

也就是說，幾乎所有基于互聯(lián)網(wǎng)的服務(wù)都是建立在事務(wù)模式上的。由于這些是我們關(guān)注的服務(wù)，觀察事務(wù)是我們?cè)诒緯忻枋龅膬?nèi)容。附錄 B 中對(duì) RUM 進(jìn)行了更詳細(xì)的描述。

可觀測(cè)性的三大支柱

考慮到事務(wù)和資源，讓我們來看看三大支柱模式。將這種關(guān)注點(diǎn)的分離標(biāo)記為 “三大支柱”，聽起來是有意的，甚至是明智的。支柱聽起來很嚴(yán)肅，就像古代雅典的帕特農(nóng)神廟。但這種安排實(shí)際上是一個(gè)意外。計(jì)算機(jī)的可觀測(cè)性由多個(gè)孤立的、垂直整合的工具鏈組成，其真正的原因只是一個(gè)平庸的故事。

這里有一個(gè)例子。假設(shè)有一個(gè)人想了解他們的程序正在執(zhí)行的事務(wù)。所以他建立了一個(gè)日志工具：一個(gè)用于記錄包含時(shí)間戳的消息的接口，一個(gè)用于將這些消息發(fā)送到某個(gè)地方的協(xié)議，以及一個(gè)用于存儲(chǔ)和檢索這些消息的數(shù)據(jù)系統(tǒng)。這足夠簡(jiǎn)單。

另一個(gè)人想監(jiān)測(cè)在任何特定時(shí)刻使用的所有資源；他想捕捉指標(biāo)。那么，他不會(huì)為此使用日志系統(tǒng)，對(duì)嗎？他想追蹤一個(gè)數(shù)值是如何隨時(shí)間變化的，并跨越一組有限的維度。很明顯，一大堆非結(jié)構(gòu)化的日志信息與這個(gè)問題沒有什么關(guān)系。因此，一個(gè)新的、完全獨(dú)立的系統(tǒng)被創(chuàng)造出來，解決了生成、傳輸和存儲(chǔ)度量的具體問題。

另一個(gè)人想要識(shí)別性能瓶頸。同樣，日志系統(tǒng)的非結(jié)構(gòu)化性質(zhì)使它變得無關(guān)緊要。識(shí)別性能瓶頸，比如一連串可以并行運(yùn)行的操作，需要我們知道事務(wù)中每個(gè)操作的持續(xù)時(shí)間以及這些操作是如何聯(lián)系在一起的。因此，我們建立了一個(gè)完全獨(dú)立的追蹤系統(tǒng)。由于新的追蹤系統(tǒng)并不打算取代現(xiàn)有的日志系統(tǒng)，所以追蹤系統(tǒng)被大量抽樣，以限制在生產(chǎn)中運(yùn)行第三個(gè)可觀測(cè)系統(tǒng)的成本。

這種零敲碎打的可觀測(cè)性方法是人類工程的一個(gè)完全自然和可理解的過程。然而，它有其局限性，不幸的是，這些局限性往往與我們?cè)诂F(xiàn)實(shí)世界中使用（和管理）這些系統(tǒng)的方式相悖。

實(shí)際上我們?nèi)绾斡^察系統(tǒng)？

讓我們來看看運(yùn)維人員在調(diào)查問題時(shí)所經(jīng)歷的實(shí)際的、不加修飾的過程。

調(diào)查包括兩個(gè)步驟：注意到有事情發(fā)生，然后確定是什么原因?qū)е铝怂陌l(fā)生。

當(dāng)我們執(zhí)行這些任務(wù)時(shí)，我們使用可觀測(cè)性工具。但是，重要的是，我們并不是孤立地使用每一個(gè)工具。我們把它們?nèi)糠旁谝黄鹗褂?。而在整個(gè)過程中，這些工具的孤立性給操作者帶來了巨大的認(rèn)知負(fù)擔(dān)。

通常情況下，當(dāng)有人注意到一個(gè)重要的指標(biāo)變得歪七扭八時(shí)，調(diào)查就開始了。在這種情況下，“毛刺” 是一個(gè)重要的術(shù)語，因?yàn)檫\(yùn)維人員在這一點(diǎn)上所掌握的唯一信息是儀表盤上一條小線的形狀，以及他們自己對(duì)該線的形狀是否看起來 “正確” 的內(nèi)部評(píng)估（圖 1-2）。

[圖片上傳失敗...(image-db1d86-1652921820395)]

<figcaption style="box-sizing: border-box; display: block; margin-top: 0.75em; margin-bottom: 1.65rem; line-height: 1.4; font-size: 0.76rem; text-align: center;">圖 1-2：傳統(tǒng)上，尋找不同數(shù)據(jù)集之間的關(guān)聯(lián)性是一種可怕的經(jīng)歷。</figcaption>

在確定了線的形狀開始看起來 “不對(duì)勁” 的那一點(diǎn)后，運(yùn)維人員將瞇起眼睛，試圖找到儀表板上同時(shí)出現(xiàn) “毛刺” 的其他線。然而，由于這些指標(biāo)是完全相互獨(dú)立的，運(yùn)維人員必須在他們的大腦中進(jìn)行比較，而不需要計(jì)算機(jī)的幫助。

不用說，盯著圖表，希望找到一個(gè)有用的關(guān)聯(lián)，需要時(shí)間和腦力，更不用說會(huì)導(dǎo)致眼睛疲勞。

就個(gè)人而言，我會(huì)用一把尺子或一張紙，只看什么東西排成一排。在 “現(xiàn)代” 儀表盤中，標(biāo)尺現(xiàn)在是作為用戶界面的一部分而繪制的線。但這只是一個(gè)粗略的解決方案。識(shí)別相關(guān)性的真正工作仍然必須發(fā)生在操作者的頭腦中，同樣沒有計(jì)算機(jī)的幫助。

在對(duì)問題有了初步的、粗略的猜測(cè)后，運(yùn)維人員通常開始調(diào)查他們認(rèn)為可能與問題有關(guān)的事務(wù)（日志）和資源（機(jī)器、進(jìn)程、配置文件）（圖 1-3）。

[圖片上傳失敗...(image-b7a756-1652921820395)]

<figcaption style="box-sizing: border-box; display: block; margin-top: 0.75em; margin-bottom: 1.65rem; line-height: 1.4; font-size: 0.76rem; text-align: center;">圖 1-3：找到與異常情況相關(guān)的日志也是一種可怕的經(jīng)歷。</figcaption>

在這里，計(jì)算機(jī)也沒有真正的幫助。日志存儲(chǔ)在一個(gè)完全獨(dú)立的系統(tǒng)中，不能與任何指標(biāo)儀表板自動(dòng)關(guān)聯(lián)。配置文件和其他服務(wù)的具體信息通常不在任何系統(tǒng)中，運(yùn)維人員必須通過 SSH 或其他方式訪問運(yùn)行中的機(jī)器來查看它們。

因此，運(yùn)維人員再次被留下尋找相關(guān)性的工作，這次是在指標(biāo)和相關(guān)日志之間。識(shí)別這些日志可能很困難；通常必須查閱源代碼才能了解可能存在的日志。

當(dāng)找到一個(gè)（可能是，希望是）相關(guān)的日志，下一步通常是確定導(dǎo)致這個(gè)日志產(chǎn)生的事件鏈。這意味著要找到同一事務(wù)中的其他日志。

缺乏關(guān)聯(lián)性給操作者帶來了巨大的負(fù)擔(dān)。非結(jié)構(gòu)化和半結(jié)構(gòu)化的日志系統(tǒng)沒有自動(dòng)索引和按事務(wù)過濾日志的機(jī)制。盡管這是迄今為止運(yùn)維人員最常見的日志工作流程，但他們不得不執(zhí)行一系列特別的查詢和過濾，將可用的日志篩選成一個(gè)子集，希望能代表事務(wù)的近似情況。為了成功，他們必須依靠應(yīng)用程序開發(fā)人員來添加各種請(qǐng)求 ID 和記錄，以便日后找到并拼接起來。

在一個(gè)小系統(tǒng)中，這種重建事務(wù)的過程是乏味的，但卻是可能的。但是一旦系統(tǒng)發(fā)展到包括許多橫向擴(kuò)展的服務(wù)，重建事務(wù)所需的時(shí)間就開始嚴(yán)重限制了調(diào)查的范圍。圖 1-4 顯示了一個(gè)涉及許多服務(wù)的復(fù)雜事務(wù)。你將如何收集所有的日志？

[圖片上傳失敗...(image-52998a-1652921820395)]

<figcaption style="box-sizing: border-box; display: block; margin-top: 0.75em; margin-bottom: 1.65rem; line-height: 1.4; font-size: 0.76rem; text-align: center;">圖 1-4：在傳統(tǒng)的日志記錄中，找到構(gòu)成一個(gè)特定事務(wù)的確切日志需要花費(fèi)大量的精力。如果系統(tǒng)變得足夠大，這幾乎成為不可能。</figcaption>

分布式追蹤是一個(gè)好的答案。它實(shí)際上擁有自動(dòng)重建一個(gè)事務(wù)所需的所有 ID 和索引工具。不幸的是，追蹤系統(tǒng)經(jīng)常被看作是用于進(jìn)行延遲分析的利基工具。因此，發(fā)送給它們的日志數(shù)據(jù)相對(duì)較少。而且，由于它們專注于延遲分析，追蹤系統(tǒng)經(jīng)常被大量采樣，使得它們與這類調(diào)查無關(guān)。

不是三根柱子，而是一股繩子

不用說，這是一個(gè)無奈之舉。上述工作流程確實(shí)代表了一種可怕的狀態(tài)。但是，由于我們已經(jīng)在這種技術(shù)體制下生活了這么久，我們往往沒有認(rèn)識(shí)到，與它可以做到的相比，它實(shí)際上是多么低效。

今天，為了了解系統(tǒng)是如何變化的，運(yùn)維人員必須首先收集大量的數(shù)據(jù)。然后，他們必須根據(jù)儀表盤顯示和日志掃描等視覺反饋，用他們的頭腦來識(shí)別這些數(shù)據(jù)的相關(guān)性。這是一種緊張的腦力勞動(dòng)。如果一個(gè)計(jì)算機(jī)程序能夠自動(dòng)掃描和關(guān)聯(lián)這些數(shù)據(jù)，那么這些腦力勞動(dòng)就是不必要的。如果運(yùn)維人員能夠?qū)Ｗ⒂谡{(diào)查他們的系統(tǒng)是如何變化的，而不需要首先確定什么在變化，那么他們將節(jié)省大量寶貴的時(shí)間。

在編寫一個(gè)能夠準(zhǔn)確執(zhí)行這種變化分析的計(jì)算機(jī)程序之前，所有這些數(shù)據(jù)點(diǎn)都需要被連接起來。日志需要被連接在一起，以便識(shí)別事務(wù)。衡量標(biāo)準(zhǔn)需要與日志聯(lián)系在一起，這樣產(chǎn)生的統(tǒng)計(jì)數(shù)據(jù)就可以與它們所測(cè)量的事務(wù)聯(lián)系起來。每個(gè)數(shù)據(jù)點(diǎn)都需要與底層系統(tǒng)資源 —— 軟件、基礎(chǔ)設(shè)施和配置細(xì)節(jié)相關(guān)聯(lián)，以便所有事件都能與整個(gè)系統(tǒng)的拓?fù)浣Y(jié)構(gòu)相關(guān)聯(lián)。

最終的結(jié)果是一個(gè)單一的、可遍歷的圖，包含了描述分布式系統(tǒng)狀態(tài)所需的所有數(shù)據(jù)，這種類型的數(shù)據(jù)結(jié)構(gòu)將給分析工具一個(gè)完整的系統(tǒng)視圖。與其說是不相連的數(shù)據(jù)的 “三根支柱”，不如說是相互連接的數(shù)據(jù)的一股繩子。

OpenTelemetry 因此誕生。如圖 1-5 所示，OpenTelemetry 是一個(gè)新的遙測(cè)系統(tǒng)，它以一種綜合的方式生成追蹤、日志和指標(biāo)。所有這些連接的數(shù)據(jù)點(diǎn)以相同的協(xié)議一起傳輸，然后可以輸入計(jì)算機(jī)程序，以確定整個(gè)數(shù)據(jù)集的相關(guān)性。

[圖片上傳失敗...(image-b0df04-1652921820395)]

<figcaption style="box-sizing: border-box; display: block; margin-top: 0.75em; margin-bottom: 1.65rem; line-height: 1.4; font-size: 0.76rem; text-align: center;">圖 1-5：OpenTelemetry 將所有這些孤立的信息，作為一個(gè)單一的、高度結(jié)構(gòu)化的數(shù)據(jù)流連接起來。</figcaption>

這種統(tǒng)一的數(shù)據(jù)是什么樣子的？在下一章，我們將把這三個(gè)支柱放在一邊，從頭開始建立一個(gè)新的模型。