這方面要跟進新動向

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

第 1 章：可觀測性的歷史

可觀測性行業正處在巨變中。

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

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

日志

記錄構成事務的各個事件。

度量

記錄構成一個事務的事件的集合。

追蹤

測量操作的延遲和識別事務中的性能瓶頸，或者類似的東西。傳統上，許多組織并不使用分布式追蹤，許多開發人員也不熟悉它。

[圖片上傳失敗...(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：可觀測性的 “三大支柱”。</figcaption>

我們用這種方法工作了很久，以致于我們不常質疑它。但正如我們將看到的，“三大支柱” 并不是一種正確的結構化的可觀測性方法。事實上，這個術語只是描述了某些技術碰巧被實現的方式，它掩蓋了關于如何實際使用我們的工具的幾個基本事實。

什么是事務和資源？

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

事務（transaction）代表了分布式系統需要執行的所有動作，以便服務能夠做一些有用的事情。加載一個網頁，購買一個裝滿物品的購物車，訂購一個共享汽車：這些都是事務的例子。重要的是要理解，事務不僅僅是數據庫事務。對每個服務的每個請求都是事務的一部分。

例如，一個事務可能從一個瀏覽器客戶端向一個網絡代理發出 HTTP 請求開始。代理首先向認證系統發出請求以驗證用戶，然后將請求轉發給前端應用服務器。應用服務器向各種數據庫和后端系統發出若干請求。例如，一個消息系統：Kafka 或 AMQP，被用來排隊等待異步處理的額外工作。所有這些工作都必須正確完成，以便向急切等待的用戶提供結果。如果任何部分失敗或耗時過長，其結果就是糟糕的體驗，所以我們需要全面理解事務。

一路下來，所有這些事務都在消耗資源（resource）。網絡服務只能處理這么多的并發請求，然后它們的性能就會下降并開始失效。這些服務可以擴大規模，但它們與可能調用鎖的數據庫互動，造成瓶頸。數據庫讀取記錄的請求可能會阻礙更新該記錄的請求，反之亦然。此外，所有這些資源都是要花錢的，在每個月的月底，你的基礎設施供應商會給你發賬單。你消耗的越多，你的賬單就越長。

如何解決某個問題或提高服務質量？要么是開發人員修改事務，要么是運維人員修改可用資源。就這樣了。這就是它的全部內容。當然，魔鬼就在細節中。

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

不是所有事情都是事務

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

也就是說，幾乎所有基于互聯網的服務都是建立在事務模式上的。由于這些是我們關注的服務，觀察事務是我們在本書中描述的內容。附錄 B 中對 RUM 進行了更詳細的描述。

可觀測性的三大支柱

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

這里有一個例子。假設有一個人想了解他們的程序正在執行的事務。所以他建立了一個日志工具：一個用于記錄包含時間戳的消息的接口，一個用于將這些消息發送到某個地方的協議，以及一個用于存儲和檢索這些消息的數據系統。這足夠簡單。

另一個人想監測在任何特定時刻使用的所有資源；他想捕捉指標。那么，他不會為此使用日志系統，對嗎？他想追蹤一個數值是如何隨時間變化的，并跨越一組有限的維度。很明顯，一大堆非結構化的日志信息與這個問題沒有什么關系。因此，一個新的、完全獨立的系統被創造出來，解決了生成、傳輸和存儲度量的具體問題。

另一個人想要識別性能瓶頸。同樣，日志系統的非結構化性質使它變得無關緊要。識別性能瓶頸，比如一連串可以并行運行的操作，需要我們知道事務中每個操作的持續時間以及這些操作是如何聯系在一起的。因此，我們建立了一個完全獨立的追蹤系統。由于新的追蹤系統并不打算取代現有的日志系統，所以追蹤系統被大量抽樣，以限制在生產中運行第三個可觀測系統的成本。

這種零敲碎打的可觀測性方法是人類工程的一個完全自然和可理解的過程。然而，它有其局限性，不幸的是，這些局限性往往與我們在現實世界中使用（和管理）這些系統的方式相悖。

實際上我們如何觀察系統？

讓我們來看看運維人員在調查問題時所經歷的實際的、不加修飾的過程。

調查包括兩個步驟：注意到有事情發生，然后確定是什么原因導致了它的發生。

當我們執行這些任務時，我們使用可觀測性工具。但是，重要的是，我們并不是孤立地使用每一個工具。我們把它們全部放在一起使用。而在整個過程中，這些工具的孤立性給操作者帶來了巨大的認知負擔。

通常情況下，當有人注意到一個重要的指標變得歪七扭八時，調查就開始了。在這種情況下，“毛刺” 是一個重要的術語，因為運維人員在這一點上所掌握的唯一信息是儀表盤上一條小線的形狀，以及他們自己對該線的形狀是否看起來 “正確” 的內部評估（圖 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：傳統上，尋找不同數據集之間的關聯性是一種可怕的經歷。</figcaption>

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

不用說，盯著圖表，希望找到一個有用的關聯，需要時間和腦力，更不用說會導致眼睛疲勞。

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

在對問題有了初步的、粗略的猜測后，運維人員通常開始調查他們認為可能與問題有關的事務（日志）和資源（機器、進程、配置文件）（圖 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：找到與異常情況相關的日志也是一種可怕的經歷。</figcaption>

在這里，計算機也沒有真正的幫助。日志存儲在一個完全獨立的系統中，不能與任何指標儀表板自動關聯。配置文件和其他服務的具體信息通常不在任何系統中，運維人員必須通過 SSH 或其他方式訪問運行中的機器來查看它們。

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

當找到一個（可能是，希望是）相關的日志，下一步通常是確定導致這個日志產生的事件鏈。這意味著要找到同一事務中的其他日志。

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

在一個小系統中，這種重建事務的過程是乏味的，但卻是可能的。但是一旦系統發展到包括許多橫向擴展的服務，重建事務所需的時間就開始嚴重限制了調查的范圍。圖 1-4 顯示了一個涉及許多服務的復雜事務。你將如何收集所有的日志？

[圖片上傳失敗...(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：在傳統的日志記錄中，找到構成一個特定事務的確切日志需要花費大量的精力。如果系統變得足夠大，這幾乎成為不可能。</figcaption>

分布式追蹤是一個好的答案。它實際上擁有自動重建一個事務所需的所有 ID 和索引工具。不幸的是，追蹤系統經常被看作是用于進行延遲分析的利基工具。因此，發送給它們的日志數據相對較少。而且，由于它們專注于延遲分析，追蹤系統經常被大量采樣，使得它們與這類調查無關。

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

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

今天，為了了解系統是如何變化的，運維人員必須首先收集大量的數據。然后，他們必須根據儀表盤顯示和日志掃描等視覺反饋，用他們的頭腦來識別這些數據的相關性。這是一種緊張的腦力勞動。如果一個計算機程序能夠自動掃描和關聯這些數據，那么這些腦力勞動就是不必要的。如果運維人員能夠專注于調查他們的系統是如何變化的，而不需要首先確定什么在變化，那么他們將節省大量寶貴的時間。

在編寫一個能夠準確執行這種變化分析的計算機程序之前，所有這些數據點都需要被連接起來。日志需要被連接在一起，以便識別事務。衡量標準需要與日志聯系在一起，這樣產生的統計數據就可以與它們所測量的事務聯系起來。每個數據點都需要與底層系統資源 —— 軟件、基礎設施和配置細節相關聯，以便所有事件都能與整個系統的拓撲結構相關聯。

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

OpenTelemetry 因此誕生。如圖 1-5 所示，OpenTelemetry 是一個新的遙測系統，它以一種綜合的方式生成追蹤、日志和指標。所有這些連接的數據點以相同的協議一起傳輸，然后可以輸入計算機程序，以確定整個數據集的相關性。

[圖片上傳失敗...(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 將所有這些孤立的信息，作為一個單一的、高度結構化的數據流連接起來。</figcaption>

這種統一的數據是什么樣子的？在下一章，我們將把這三個支柱放在一邊，從頭開始建立一個新的模型。