可觀測平臺：滴滴可觀測性的實現

可觀測性（Observability）是近年來備受關注的話題。那什麼是可觀測性？別急，讓我們先從一個常見的場景開始：

你是一個一線開發同學，在某天上班路上收到了一個電話報警，提示某個接口的錯誤數超過了閾值 30。得益於公司監控團隊做的所謂 chatops，幾經周折後，你終於在 IM 中打開了對應的監控圖表，發現當前的錯誤數似乎比之前多了一些。

作爲服務開發者的你，昨天晚上部署了一個新版本，並且依賴的服務好像也做了變更。你開始猜測這個報警是否與你昨晚的上線有關，但怎麼也回憶不起來昨晚依賴服務的變更內容了。

你的組長打電話過來詢問報警的情況。搞不清狀況的你只能回答” 我需要看一下”。你打開電腦連上熱點並登錄上了機器，tail -f xxx.log | grep -E 'error|timeout|code=9527'。一通猛如虎的操作，你發現了問題所在，是你依賴的另一個服務延遲過高導致。和你的上線無關，和昨晚變更的依賴服務也無關。

上述這個場景，很多同學都遇到過。我們從中會發現一些問題：

• 缺乏進一步分解和深入分析的能力： 得到監控產出的圖表後，無法進行進一步的分解，我們不得不跳出當前上下文，使用如 tail、grep、tcpdump、strace 等工具進行問題追查。

• 複雜的微服務架構難以定位問題來源： 因爲複雜的微服務架構，無法確定問題源自哪裏，是服務自身還是依賴的服務出現問題。

• 難以確定合理的報警規則： 不能確定諸如 if len(error) > 30；then alert() 這樣的行爲是否合理。

• 排查問題依賴我們的歷史經驗： 例如 9527 這樣的 code，是上一次故障添加的，用於識別某類錯誤，但這類錯誤可能永遠都不會再出現，只是不知爲何這個數字在我們腦海裏印象頗深，出於短期的記憶，順手作爲了過濾條件之一。

這些問題如何解決？需要依靠可觀測性。可觀測性在計算機領域目前仍沒有標準的定義，但已經有了一些共識：如果你能從外部，理解一個系統所處的任何狀態，這些狀態不需要是預定義的（例如 9527），它們可能出現過也可能從未出現。當新的狀態出現時，也不需要你重新埋點、發佈新代碼，那麼我們說這個系統就具備了可觀測性。

基於上述對可觀測性的描述，我們從幾個方面簡單比較所熟知的監控與可觀測性，以便大家能夠更直觀地理解它們的區別：

• 監控關注聚合值，可觀測性關注明細：在傳統的監控中，通常會採集和展示聚合後的指標值，如平均值、最大值、最小值等，用於判斷系統的整體狀態。而可觀測性更注重收集和展示明細信息，比如原始日誌、指標的分佈情況等，使得開發人員能夠深入瞭解每個細節，從而更好地發現問題和優化系統。

• 監控使用閾值，手動或自動與閾值進行比較，或依據歷史經驗或者是早已經過期了的 run book 來猜測當前系統的狀態。可觀測性因爲擁有明細信息，所以倡導和鼓勵用戶主動去探索和了解系統，從而能更準確地發現問題。

• 監控面向有經驗的工程師，可觀測性面向所有工程師。

總的來說，可觀測性的目標是爲了讓我們更好地瞭解系統的運行情況，從而能夠更快速地發現和解決問題，提高系統的穩定性。它強調的是全面的、詳細的數據，鼓勵用戶主動去探索和發現，而不僅僅是被動地接收那些我們自己都無法確定閾值的報警通知。

可觀測性實現

上一節我們簡單描述了一下可觀測性優於監控的地方。那如何實現可觀測性？可觀測性期望儘可能多的保留請求上下文，以便探索導致故障（可能是歷史的也可能是新的）的環境和細節狀態。因此可觀測性在信息的豐富程度上，要求比監控高很多，需要用戶暴露更多的信息（例如豐富 Metrics 的 Label），但這樣一來，用戶的成本可能就控制不住了。

畫外：說來說去你不就是要加錢麼？

作者：秀兒同學，請你先坐下。

如果按照一些 SAAS 廠商的推薦做法，上報幾十幾百的維度，每個維度下不限制基數，的確可以達成可觀測性的先決條件。但有 2 個現實問題：

1. 上報如此豐富的數據，用戶成本將會爆炸性地增長。

2. 現存的存儲解決方案，很難能扛住如此高維度 + 高基數 + 大量級的數據。

畫外：你就不能自己實現一個麼？

作者：保安在麼，請秀兒同學出去。

除了一些 SAAS 廠商倡導的 high dimensionality, high cardinality 論調外，開源屆更傾向於採用 “曲線救國” 的方式，通過關聯當下主要的觀測信號來實現可觀測性。這些主要的觀測信號包括：Metrics（指標）、Traces（分佈式追蹤）、Logs（日誌）等。關聯論期望關聯 Metrics 的高層次抽象 + Traces 的跨服務的上下文關聯 + Logs 暴露最詳細的 Human-Readable/Acceptable 信息的形式，達到可觀測的目標。

滴滴的可觀測性實現

答案是結合這兩者，以平衡成本、效率和實現可觀測性的目標。在實現上，我們改造了日誌採集和 Metrics 採集的方式，對低基數和高基數維度進行切分，分別存儲到不同的後端存儲中，並建立關聯關係。對用戶暴露其關心的日誌原文、traceID 等信息，從而實現可觀測性。

具體來說，對於日誌採集，在採集端實時分析日誌生成監控曲線的過程中，會按照給定的週期，採樣上報一條日誌原文及其與監控曲線的對應關係。對於 Metrics 採集，需要用戶調用埋點代碼時傳遞額外的參數，告訴我們希望採樣保存的維信息，這個額外維在生產環境中一般會被設置爲 TraceID，它不會出現在 Metrics 曲線的 Label 中，我們每個週期採樣上報一條額外維的信息，及其和監控曲線的對應關係。

滴滴可觀測性產品介紹

可觀測性不僅僅需要在技術層面考慮，更要完善產品以幫助用戶從監控到可觀測性的升級。下面，我們將介紹幾個常用的場景，並結合前文所述，深入感受可觀測性帶來的便利性和可探索性。

報警現場關聯日誌原文

如果配置的策略發出了報警通知，可以直接在 IM 中查看你最熟悉的日誌原文，基於日誌原文進行下一步的決策，無需登錄機器，無需 tail、grep 等。

圖 1: 報警現場關聯日誌原文

曲線看圖關聯日誌原文、TraceID

只是在報警時刻使用還不夠，還可以在看圖時下鑽日誌原文，我們已將提取的日誌原文進行簡單清洗，當識別到 TraceID 時，可以直接跳轉到 Trace 平臺進行上下游服務的排查：

圖 2: 曲線看圖關聯日誌原文、TraceID

結尾

通過建立 Logs、Traces 和 Metrics 這幾個觀測信號的關聯，這套內部稱之爲 MTL 的架構和產品，在滴滴的可觀測體系中發揮着重要作用，使得開發人員和運維團隊可以更加了解其系統的運行狀態，從而更準確地發現問題和進行故障排查，這套系統也得到了衆多用戶的認可和正向評價。希望通過這篇文章，能爲大家提供一些經驗和啓示。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/03YwQyqbT_WO1PXa70ZHJQ