可觀測性與追蹤

可觀測性與監控(observability versus monitoring)

想像汽車的儀表板。監控就是製造商選擇裝上的那組儀表:時速、油量、引擎溫度。它們回答的是某人事先決定值得問的問題。但當車子發出一個沒有任何儀表涵蓋的奇怪新聲音時,儀表幫不上忙——你需要一種方法,去問一個沒人預先規劃過的問題,而且不能把引擎拆開。後面這種能力,就是人們說的可觀測性。

更精確地說:監控(monitoring)是指盯著一組事先選定、已知的訊號,並在某個訊號越過門檻時發出警報——它回答你早就知道要問的問題。可觀測性(observability)則是指系統發出夠豐富的資料,讓你事後能對它提出「新」問題,包括你當初沒料到的問題,而且不必修改或停止正在運行的系統。被監控的系統告訴你「有東西壞了」(錯誤率上升了);可觀測的系統則讓你探究「為什麼」,方法是在查詢當下,沿著你自己選的維度切分資料(哪個客戶、哪個版本、哪台主機、哪條程式碼路徑)。常被引用的實務檢驗是:你能否只用系統已經輸出的資料,去除錯一個你從沒見過的新問題?若能,它就是可觀測的。

它之所以重要,是因為現代正式環境系統會以沒人預測到的方式故障——某個特定使用者、某個特定請求、某個特定節點的罕見組合。預先定義好的儀表板無法涵蓋你沒預見的組合。可觀測性是一門紀律:發出高基數、結構化的訊號(metrics、logs、traces),好讓答案早已在資料裡,你只需要去查詢它。誠實的提醒:可觀測性不是一個你買得到的產品、也不是一塊你裝上去的儀表板——它是「你的系統對自己揭露了多少」這個性質;你可以在工具上花大錢,卻仍然回答不出那個真正重要的問題。

監控:當 http_5xx_rate > 1% 時發警報 可觀測性:查詢延遲,依 (customer_id, build_version, host) 分組 -> 「所有慢請求都是客戶 4821、在 build 9f3a 上,而且只發生在主機 db-7」

監控觸發一個已知警報;可觀測性讓你在查詢時用自選的維度切分,找出一個沒預見過的原因。

兩者不是對立、也不互相取代:你仍然需要監控(對已知故障模式做便宜又快的警報),也需要可觀測性(深入的臨時提問)。被當成行銷標籤的「可觀測性」往往只是把監控改名而已——用「你能不能問一個沒人事先做好的問題」來判斷它。

又称
observabilitymonitoring可觀測性監控