Charity Majors 的這句話可能是對科技行業當前可觀察性狀態的最好總結——完全的、大規模的混亂。大家都很困惑。什麼是 trace？什麼是 span？一行日誌就是一個 span 嗎？如果我有日誌，我還需要 trace 嗎？如果我有很好的 metric，為什麼還需要 trace？諸如此類的問題不勝列舉。Charity 與 Honeycomb 可觀測系統中的其他傑出人士一起，一直在努力解決這些問題。然而，根據我自己的經驗，仍然很難解釋 Charity 所說的“日誌是垃圾”是什麼意思，更不用說日誌和痕跡本質上是同一件事了。為什麼大家都這麼困惑呢？
冒一點風險，我要怪罪 Open Telemetry。是的，它正在為現代的可觀測性堆疊提供動力，然而我卻將混亂的局面歸咎於它。這並不是因為它是一個糟糕的解決方案 - 它非常出色！但是它本身的介紹、對 Open Telemetry 的概念和功能的講解，都使得可觀測性看起來棘手而複雜。
首先，Open Telemetry 從一開始就明確區分了跟蹤、指標和日誌：
OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.
OpenTelemetry 是 API、SDK 和工具的集合。使用它來檢測、生成、收集和匯出遙測資料（指標、日誌和跟蹤），以幫助您分析軟體的效能和行為。
然後進一步深入解釋這 3 個問題中的每一個。
這是 OpenTelemetry 網站介紹 trace 的部分截圖。根據我與 OpenTelemetry 工作人員交談的經驗，該簡報確實已成為與可觀測性相關的主要圖片之一。對於一些人來說，這就是可觀測性。它還將 trace 與其他任何東西區分開來。這顯然不是日誌，對吧？這看起來也不像指標，對吧？這是一些特別的東西，可能有點牛逼，需要投入學習。根據我的經驗，一旦人們瞭解了 trace，他們只會在這張圖片的上下文中思考它們以及相關術語，如 span、根 span、巢狀 span 等。OpenTelemetry 網站有一個包含 60 多個術語的詞彙表頁面！這一切都極其複雜！
但更重要的是——這種對“日誌、指標和鏈路追蹤”的關注是否代表了可觀察性的真正力量？確實，它確實涵蓋了一些場景，但當涉及到大規模分散式系統時，更重要的是能夠對資料進行深入挖掘 - 對其進行“切片和切塊”，構建和分析各種檢視，進行相關性分析，搜尋異常情況… 而提供所有這些功能的系統確實存在。
Scuba: 可觀測性天堂
當我在 Meta 公司工作時，我並沒有意識到我有幸使用了有史以來最好的可觀測性系統。這個系統稱為 Scuba，它是離開 Meta 公司後人們最懷念的頭等大事。
Scuba 的基本思想非常簡單，不需要人們閱讀術語頁面就能理解。它使用廣義事件（Wide Events）。廣義事件只是一個帶有名稱和值的欄位集合，就像一個JSON文件一樣。如果你需要記錄一些資訊 - 無論是系統的當前狀態還是由API呼叫、後臺作業或其他事件引起的 - 你只需將一些廣義事件寫入Scuba。例如，如果一個系統提供廣告服務，自然希望記錄廣告展示 - 即某個廣告被使用者看到的事實。相應的廣義事件可能如下所示：
{
"Timestamp": "1707951423",
"AdId": "542508c92f6f47c2916691d6e8551279”,
"UserCountry": "US",
"Placement": "mobile_feed",
"CampaingType": "direct_ads",
"UserOS": "Android",
"OSVersion": "14",
"AppVersion": "798de3c28b074df9a24a479ce98302b6",
"...": ""
}這樣的事件被稱為廣義事件，因為鼓勵將所有能想到的資訊都儲存在其中。在特定資料的上下文中可能相關的任何東西 - 只需將其放在那裡，它可能在以後有用。這種方法為處理未知的未知情況奠定了基礎 - 即現在無法想到的、在事故調查過程中可能會揭示的事情。
處理未知的未知情況可以透過一個例子更好地說明。Scuba擁有一個直觀易用的介面，可以輕鬆探索和操作。它有一個部分可以選擇要檢視的指標，還有用於篩選和分組的部分 - Scuba會繪製一個漂亮的時間序列圖表。對於廣告展示資料集的首次檢視將簡單地繪製一個包含展示次數的圖表：
如果我們用 SQL 來表達這裡到底選擇了什麼，那麼這就像：
SELECT COUNT(*) FROM AdImpressions
WHERE IsTest = False實際情況並非完全如此。Scuba 還具有原生取樣的概念。當某個事件被寫入 Scuba 時，還必須寫入一個稱為 samplingRate 的欄位，表示此特定事件的取樣率。Scuba 使用此資訊來正確地“放大”圖表上顯示的結果，因此無需在頭腦中進行這種放大操作。這是一個非常棒的概念，因為它允許動態取樣 - 例如，某種型別的展示可能比另一種型別的展示更頻繁地進行取樣，同時保留 UI 中的“真實”值。因此，底層的實際查詢是：
請注意，整個“放大”是由 UI 透明完成的，使用者在查詢期間無需考慮它。因此，假設發生了某個警報，並指示我們珍貴的廣告展示圖表看起來很奇怪：
每個使用 Scuba 進行調查的人的第一反應是進行“切片和切塊”，即根據條件進行篩選或分組，以檢視是否能夠獲取一些資訊。我們不知道我們在尋找什麼，但我們相信我們會找到。因此，我們會根據展示型別、使用者國家或廣告位置進行分組，直到找到可疑的地方。讓我們假設是按照廣告系列型別（CampaignType）進行分組：
我們發現某個名為 in_app_purchases 的廣告系列型別（請注意，此型別名稱是我編造的）似乎與其他型別不同。我們真的不知道它意味著什麼 - 我們也不需要知道！ - 我們只需繼續挖掘。好的，現在我們可以僅篩選這些廣告系列，並繼續根據其他我們能想到的條件進行分組。例如，使用者作業系統是有意義的。
嗯，Android 似乎有問題。iOS 沒問題，這表明問題可能出現在客戶端 - 可能是一個有問題的應用版本？
奇怪。有些人遇到了問題，而其他人沒有。可能要檢查作業系統版本？
哈！這是最新的作業系統版本，看起來某些應用版本在這個作業系統版本上對於這種型別的廣告系列表現不佳。鑑於這些資訊，專門的團隊現在可以深入研究了。
發生了什麼？在沒有任何關於系統的知識的情況下，我們已經縮小了問題的範圍，並確定了負責進一步調查的團隊。我們能事先知道這種奇怪的作業系統、作業系統版本、廣告系列型別和應用版本的組合可能會導致一些問題，並準備好相應的度量指標嗎？當然不可能。這是處理未知的未知情況的一個例子。我們只是將所有相關的上下文資訊儲存在廣義事件中，並在需要時使用它們。Scuba使得探索變得簡單，因為它快速且具有非常漂亮易用的使用者介面。還請注意，我們從未提及過基數的任何內容。因為這並不重要 - 任何欄位都可以具有任何基數。Scuba使用原始事件進行操作，不進行預聚合，因此基數不是一個問題。
有時候介面/視覺化方面沒有得到足夠的關注，監測系統提供了一些查詢語言 - 可能是專有的（不好-不好-不好），或者是SQL（稍微好一些，但仍然不好）。這樣的介面幾乎不可能進行類似的調查。Scuba的一個重要方面是所有欄位（函式、篩選、分組等）都是可探索的。也就是說，有一種簡單的方法可以檢視我們可以選擇的值的型別。當某個欄位的所有者不懶惰時，他們甚至會為給定欄位提供詳細的描述，包括相關連結等。這非常重要。我成功地進行了許多調查，而我對整個系統或該資料集中的可用資料並沒有完全瞭解。而且在這些調查過程中，我透過與Scuba的互動簡單地瞭解了很多關於系統的知識！這太神奇了。這就是可觀測性的天堂。
離開 Meta 之後的痛苦
現在想象一下，當我離開 Meta 並瞭解到外部的可觀測性系統的狀況時，我有多麼困惑和難以置信。
日誌？追蹤？指標？這到底是什麼？有人知道廣義事件嗎？我可否不去學習那60個術語的術語表，只是…探索一下東西？
我花了相當長的時間將基於 Scuba 的心智模型對映到 Open Telemetry 的心智模型上。我意識到 Open Telemetry 的 Span 其實就是廣義事件。實際上，我仍然不太確定我是否理解正確：
如果我們以廣告展示為例，這個展示實際上並不是一項操作，它只是我們想要記錄的一些事實… 公平地說，在 Open Telemetry 中確實存在事件（Event）的概念：
但如果我們按照連結深入挖掘，我們會再次發現事件實際上是跟蹤、指標或日誌之一 🤷
但無論如何，Span 是與廣義事件最接近的概念。問題是 - 當已經習慣了 Open Telemetry 提出的心智模型時，很難為這種心智模型進行辯護。這真的很令人沮喪，因為追蹤、指標和日誌實際上都只是廣義事件的特例：
- 追蹤和跨度（Spans）：它們只是具有 SpanId、TraceId 和 ParentSpanId 欄位的廣義事件而已。因此，我們可以使用給定的 TraceId 過濾所有跨度（Spans），根據 SpanId → ParentSpanId 的關係對它們進行拓撲排序，並繪製出每個人都喜歡的分散式跟蹤檢視。
- 日誌：說實話，我對Open Telemetry所說的日誌真的感到困惑。看起來它包含很多東西，其中之一是結構化日誌，這基本上就是寬事件。太好了！然而，問題在於“日誌”是一個相當明確的概念，通常人們指的是那些
logger.info(…)呼叫所產生的東西。不管怎樣，無論是什麼含義，日誌當然可以很容易地對映到寬事件。在最簡單的情況下，我們只需獲取日誌訊息，將其放入“log_message”欄位，新增一堆後設資料，然後就可以滿意了。在更復雜的情況下，我們可以嘗試透過移除看起來像ID的令牌，從日誌訊息中自動提取一個模板，並獲取這個模板的雜湊值。這可以讓我們快速獲取最頻繁的錯誤，例如，透過按這個雜湊值進行分組。Meta有這樣一個系統，它非常酷。 - 指標：指標也可以很容易地對映。我們只需要在某個間隔內發出一個包含系統狀態（例如CPU系統指標、各種計數器等）的寬事件。順便說一下，Prometheus正是透過抓取方法做到這一點的——偶爾對系統進行一次快照。然而，與Prometheus不同，使用寬事件方法我們不需要擔心基數問題。
但是寬事件（Wide Events）可以提供比這些“三大支柱”（Traces, Logs, Metrics）多得多的東西。前面提到的除錯會話已經是一個（至少不是自然地）由追蹤（Traces）、日誌（Logs）和指標（Metrics）所涵蓋的案例。也可能有其他的用例——例如，continuous profiling 資料可以很容易地表示為一個寬事件（Wide Event），並被查詢以構建火焰圖（Flame Graph）。沒有必要為此擁有一個單獨的系統——一個單一的系統處理寬事件就可以做到這一切。想象一下，當所有東西都儲存在一起、在一個地方時，交叉相關性（cross-correlation）和根本原因分析（root cause analysis）的可能性。特別是在人工智慧工具興起的時代，這些工具在發現資料中的關係方面非常出色。
所以，然後？
我不知道… 我只是想表達我的失望和挫敗感，可觀測性如此混亂讓人困惑，而且還專注在什麼“三大支柱”…
我只是希望可觀測性（observability）供應商能站出來反對混亂，並提供一種簡單自然的方式與系統互動。Honeycomb似乎正在這樣做，還有一些其他系統，比如Axiom也在這樣做。這很棒！希望其他供應商也能效仿。
附
本文是譯文，原文：https://isburmistrov.substack.com/p/all-you-need-is-wide-events-not-metrics
文末請允許我插播一個小廣告。本人創業兩年了，我們公司也是做可觀測性，和本文思路有些相像之處。如果你有這方面的需求，歡迎聯絡我們做產品技術交流哈。
🎯 關於快貓星雲
快貓星雲是一家雲原生智慧運維科技公司，由知名開源專案“夜鶯(Nightingale)”的核心開發團隊組成，創始團隊均來⾃阿⾥、百度、滴滴等互聯⽹公司。夜鶯是一款開源雲原生監控工具，是中國計算機學會接受捐贈並託管的第一個開源專案，在GitHub上有超過8000顆星，迭代釋出了超過100多個版本，上百位社群貢獻者，是國內領先的開源可觀測性解決方案。
快貓星雲以開源夜鶯為核心打造的“Flashcat平臺”，是國內頂級互聯⽹公司可觀測性實踐的產品化落地，致力於讓可觀測性技術更好的服務企業，保障服務穩定性。Flashcat 平臺具有以下特點：
- 統一採集：採用外掛化思路，內建整合上百種採集外掛，伺服器、網路裝置、中介軟體、資料庫、應用、業務，均可監控，開箱即用。
- 統一告警：支援幾十種資料來源對接，收集各類監控系統的告警事件，進行統一的告警收斂、降噪、排班、認領、升級、協同，大幅提升告警處理效率。
- 統一觀測：將 Metrics、Logs、Traces、Events、Profiling 等多種可觀測性資料融會貫通，並預置行業最佳實踐，既提供全域性業務視角、技術視角的駕駛艙，也提供層層下鑽的故障定位能力，有效縮短故障發現和定位時間。
快貓星雲，讓可觀測性資料更有價值！
https://flashcat.cloud/