高德打車構建可觀測性系統實踐

一  寫在前面

互聯網工程的高速發展，分佈式、微服務、容器化架構的流行，互聯網已全面進入雲原生時代。構建系統的方式由最初的單體大應用演變爲分佈式架構，一臺服務器可能僅存幾小時甚至幾分鐘，這種複雜性大大增加了把系統運行狀態可視化的難度。

高德打車業務的發展歷程也不例外，同樣經歷了從單體大應用到服務化拆分的過程，龐大的應用體系和架構的不斷升級，保障了多個節假日出行高峯的穩定，業務仍在持續快速的發展中，如何保障這套龐大又複雜的系統持續高性能、高可用、高可控？構建 360 度無死角的多維度可觀測能力顯得愈發重要。

二  談系統可觀測性

1  什麼是系統可觀測性

可觀測性 (observerbality)，是一個最近幾年開始在監控社區流行起來的術語，可觀測性的提出最早來自於 Google 著名的 SRE 體系和 Apple 工程師 Cindy Sridharan 的博文《Monitoring and Oberservability》，感興趣的同學可以看一下。

可觀測性不是一種具體的工具或技術，更偏向於是一種理念，目前已成爲複雜分佈式系統成功管理的關鍵組成部分，它是指運行中的系統可被調試的能力，這種可調試能力的核心就是能夠在系統運行時對其理解、詢問、探查和調度。

理解，詢問，探查體現在幫助工程師發現問題 -> 定位問題 -> 解決問題 (止損)，調度體現在可根據系統運行狀態做出的自動化，智能化決策的能力。

可觀測性的目標是增強工程師對系統運行狀況的瞭解，增強對系統的信心。

目前，業界廣泛推行的可觀測性包含三大支柱：日誌事件 (Logging)，分佈式鏈路追蹤 (Tracing) 和 指標監控 (Metrics）。

2  可觀測性與監控的關係

可觀測性 != 監控

第一印象很容易把 “可觀測性” 認爲就是“監控”，人類一般傾向於用之前的認知來理解一些新概念，其實兩者是不一樣的。

監控是機器代替人工，長期的觀察系統的行爲和輸出，幫助團隊觀察和了解其系統狀態的工具或技術解決方案。監控與可觀測性的區別如下：

關注點不同

監控更多關注的是具體指標的變化和報警，關注系統的失敗因素，多與運維相關，強調從外到內，從外部通過各種技術手段去看到內部，關注的是點。而可觀測性關注的是應用本身的狀態，是對系統的一種自我審視，強調從內到外，站在宏觀的角度去聚合分析各種指標，不僅瞭解分佈式系統所有鏈路的運行狀況，還能在多指標同時發生問題時知道什麼是因，什麼是果，讓工程師 “理解” 系統發生的一切行爲，關注的是點線面的結合。

關注時間不同

監控更加註重問題的發現與預警，關注軟件交付過程中以及交付後的 1 到 2 天，也就是我們常說的 “事中與事後”。而“可觀測性” 是要對一個複雜分佈式系統所發生的一切行爲給出合理解釋，關注的是研發與運維的全生命週期。

目的不同

監控是告訴我們系統在什麼時間、什麼地方、發生了什麼問題，僅提供對已知問題或故障的答案。而可觀測性是爲了告訴我們那裏爲什麼發生了問題，還允許工程師提出新問題。具備可觀測性的系統，工程師既可以直觀的觀察到系統的整體運行狀態，又可以輕易深入到系統運行的各個細節角落。在正常運行時，能對系統進行評估，提供操作建議，在發生故障時，可協助工程師快速理解、定位和修復問題。

監控與可觀測性又是相輔相成的，監控是可觀測性的一項基礎設施和手段，監控是可觀測性的子集，抽象如下圖：

三  我們做了什麼

分享下高德打車在探索可觀測性系統建設過程中的一些具體實踐，交流學習。

1  統一日誌

首先對日誌進行了統一治理，日誌事件 (Logging) 是可觀測性的三大支柱之一，當應用數上百，微服務數上千時，各應用的日誌還任由開發人員根據自己喜好隨心所欲的打，可能會形成一場噩夢。例如五花八門的格式、級別、分類，甚至於 error 和 info 都混雜在一起。我們將日誌統一歸爲三類：監控日誌，業務日誌，錯誤日誌，並封裝提供專門的日誌 sdk，將 “有效” 的日誌進行統一管控，還能間接達到控制成本的目的。

監控日誌

監控日誌只用來做監控，和其他日誌進行區分，輸出到一個單獨的滾動文件裏。

監控的原則是用來發現問題，而不是用來定位問題，要定位具體的問題，需要更詳細的日誌，通過監控日誌中的 traceId 去關聯其他內容即可。

監控日誌統一以 monitor 開頭，業務較多時，也可分多個，如 monitor-biz1.log, monitor-biz2.log。監控日誌分隔符固定用豎線 | , 監控指標成功失敗統一歸類爲 success，fail (業務失敗)，error (接口失敗)。耗時邏輯統一在 sdk 中實現，刪除原代碼中遍地存在的 long start=System.currentTimeMillis()。

統一監控日誌還有另一個好處：當開發人員看到調用監控日誌 api 的代碼，會自然而然引起內心的重視，明白這是用來做監控的，我不能隨意修改，避免不同開發人員協作時誤改代碼而導致監控錯誤。

sdk 僞代碼：

//定義key值，標記起始時間
MonitorLog mlog = MonitorLog.start("access", "url", "httpcode", "bizcode");
try {
    //doSomeThing1...
    //標記start到something1 做完後的時間
    mlog.addTimeScope("time1");
    //doSomeThing2...
    if ("成功") {
        mlog.success(url, httpStatus, response_code);
    } else {
        mlog.faild(url, httpStatus, response_code);
    }
} catch (Exception e) {
    mlog.error(url, httpStatus, response_code);
}

業務日誌

這裏的業務日誌並不是指代碼中開發人員隨意打出的 log.info(...) ，而是指專用於定位業務問題，根據自己的業務特點，經過認真規劃，打出的需要統一收集、存儲和分析的業務相關的日誌。

含關鍵信息，非關鍵信息，附加信息：

錯誤日誌

錯誤日誌也進行格式統一，方便對異常的全鏈路分析和追蹤。格式舉例如下，如果某一項沒有數據，會使用'-'進行佔位。

2  全鏈路追蹤

分佈式全鏈路追蹤 (Tracing) 是可觀測性的第二大支柱，全局唯一的 TraceId 利用阿里中間件鷹眼 Id 的現成解決方案實現，保證了在整個鏈路的唯一性，然後解決掉在分佈式調用鏈路中，同步改異步丟失 traceId 的問題，該 traceId 會同時在監控日誌，服務日誌，和錯誤日誌以及其他日誌中透傳並記錄，traceId 持續的傳下去，就是給整個請求鏈路打上了標記，鏈路上涉及的所有應用日誌收錄到阿里雲 SLS，接入阿里雲 api，通過 api 拿到所有應用的日誌，通過 TraceId 就可以還原這次請求的整個上下文。

市面上有很多 APM 廠商，監控社區也有很多開源的鏈路追蹤系統均可採用。

3  監控治理

這一階段我傾向於稱作是對可觀測系統第三大支柱 (Metrics) 的實現，是監控的梳理、補全優化階段。“巧婦難爲無米之炊”，如果基礎監控項都覆蓋不全，何談可觀測性。

這裏我把監控歸類爲 5 個領域，如圖：

提醒一下，監控體系建設沒有銀彈，任何值得解決的事情都需要爲之付出努力，不要幻想有一種工具能一下子解決你所有的監控問題。

再提一個監控建設的反模式 “勾選式” 監控。就是按照各種文檔和要求，把各種監控工具都用上，然後就開始自嗨的認爲自己的系統就會健壯無比，高枕無憂，這就是典型的 “勾選式” 監控，爲了使用而使用，不會有好的效果。

分類介紹下上圖監控體系的 5 個領域：

基礎設施監控

首先是對於機器和操作系統環境的各項基礎指標監控：cpu，mem，load，io，磁盤等，相信任何一個成熟的監控平臺都會具備這項基礎能力，不再贅述。

中間件監控

各種中間件的使用是分佈式系統的重要元素，對於中間件的監控要遵循各個中間件的監控規範，推薦使用中間件自己的日誌，指標模板等，不必重複造輪，口徑統一也會減少溝通成本。

應用 & 業務監控

應用監控統一歸納爲請求量，耗時，成功率三類，稱爲三大黃金指標：

將應用監控的各項指標進行統一，一方面可以方便的查漏補缺，按照應用和接口 list，挨個檢查，有則完善，無則補充，另一方面可以減少溝通成本，不同的應用指標統一後，也降低了跨應用排查問題的複雜度和困難度。

業務監控是不同開發同學基於自己的業務日誌建設而來，應包含業務的量級監控，趨勢監控，還有各種轉化率，轉化漏斗的監控，很多問題單靠量級和趨勢是發現不了的。業務轉化率和轉化漏斗是相對複雜的邏輯，且此類數據的報表一般都是 BI 做的 T+1 報表，及時性不夠，缺少實時的轉化率和轉化漏斗監控，會讓我們漏掉很多問題，問題發現時往往已經過去很久，此類複雜業務指標監控可以基於 flink 一類的流式計算來實現，即使做不到實時，能做到準實時，分鐘級，小時級作用也是很大的，是對業務指標監控的重大提升。

業務監控這裏不得不提場景監控，不同場景流量的規模是完全不同的。比如同一個微服務接口被不同的業務場景調用，只對接口級別的指標進行監控的話，流量小的場景錯誤數量很容易被流量大的場景錯誤量所淹沒，在異常發生時，監控不報警，所以業務監控要做到針對場景的細分，可以指導我們做精細化的控制。

資損監控

應用和業務監控指標正常，不代表服務就是正常的。數據的正確性校驗，最終一致性校驗，資金安全問題同樣是很嚴峻的問題，很容易被忽略。數據監控和資損防控能力也應是監控必備的能力，尤其是大促期間，上線各種促銷補貼，促銷活動和玩法，對資金安全提出更多挑戰，防止用戶 / 平臺 / 服務商的資金損失，是對我們服務的基本要求。涉及數據覈對，資損的防控一般都會涉及多方，因爲要多方對賬，一定要充分溝通，重要的資金風險場景都要覆蓋到，監控時效性做不到實時的話，準實時和離線小時級是要必備的。

監控大盤

有了各個應用準確的監控項做基礎，還需要建立核心業務鏈路的監控大盤。大盤有技術指標維度的，還要有業務指標維度。大盤的指標擺放遵循：秒級指標，分鐘級指標，成功率，下游依賴成功率，耗時，下游依賴耗時等。layout 提前設計，不能太寬鬆也不能太滿，一行 2-3 個最好，趨勢圖和表格要共存，趨勢圖在數據源太多時展示同環比會很難看。

監控降噪

監控不能只是一味的增加，而不去保鮮，那是濫用，會產生很多恐怖的可能性。高德打車業務亦是如此，隨着業務的發展，新老監控達到一定的量級，有些指標已經年久失修，數據不準仍每天報警，釘釘消息和短信數量爆炸，動輒未讀 99+，已經對工程師造成嚴重干擾。

降噪的原則是每個報警項都應該是可執行的，報出來就是需要依靠人的智慧來作出反應，而不應是機器人或腳本去自動迴應。如果報警信息不能指導人的行動，就是噪音，浪費精力去關注。

監控降噪有 2 方面內容：

監控的名稱語義要準確，見名知意，光看名字就能迅速知道是哪塊業務出的問題，節省時間，方便值班人員周知相關人員。特別是一些 url 類的監控，已知的 url 要儘可能用到翻譯，很少有人記得清這個 url 是幹什麼的。

中間件類的監控項名稱中最好包含中間件的名稱、類型、以及應用或業務名等。如：中間件_RPC_生產者 / 消費者_類別 (成功失敗彙總 / 耗時 / 錯誤碼等)_應用名。

通知渠道

報警要有級別概念，根據指標核心程度，緊急程度，要區分不同的渠道，高級別監控指標要有短信或電話報警，短信和電話報警不宜過多，緊急程度不能無腦 P0。

4  指標關聯、拓撲、可視化

這一階段我稱作是對系統整體可觀測能力的實現，目的是要能 “理解” 系統的一切行爲。

前面 3 點做完了，你可能還會遇到很多類似的尷尬問題：監控系統顯示爲 “正常”，但是我們的客服卻不斷收到客訴，甚至業務系統已經不能正常工作了，另外一種情況就是你已經發現監控各種在報警，卻沒辦法告知哪塊業務會受到影響，哪裏會不工作，在規模化微服務之後，你可能連宏觀的關聯關係都發現不了，更別談對系統行爲的 “理解”。這就是在當今雲原生時代下的大型分佈式系統中，可觀測性相對於傳統監控要解決的問題。

單純的指標集監控可能會是一個不成體系的狀態，在這種狀態下，工程師衡量系統的運行狀態，多是靠一些零散指標，或是靠一些元老級工程師通過自己經驗，從多個指標裏模糊構建出業務全局狀態，盲人摸象，是看不清全局的，而這些經驗也往往是不可複用的。更合理的做法是站在創造者的角度去探究如何讓系統正確的展現自身的狀態，通過技術手段建立系統監控的可觀測性，既能從微觀角度去看一個請求的完整鏈路，又能從宏觀角度去分析問題，“看清” 系統運行的全面狀態，降低經驗門檻和不確定性。

有效實施可觀測性的第一要點就是要拆分指標，建立指標關聯和拓撲，方式有很多，這裏參考 OSM 數據分析模型法的方式，將監控指標分層進行拆解，細化到可落地執行的指標細項。

做監控指標的拆分並不是要求像 OSM 那樣嚴格的按照 3 層去拆，只是借鑑一個理念，先整體的看業務全局，結合產品目標，業務鏈路，拆分出可執行，都認可的一級指標，以高德打車業務爲例，最終定義出一級指標是下單，綁單，完單，支付：

對一級指標建立監控，建立量級和轉化漏斗的多維度指標，如下單量，綁單量，下單量同環比，下單量趨勢，業務轉化漏斗綁單率，完單率，支付率等。

接下來選擇一級指標 “完單量” 爲例，再繼續進行二級指標的拆分，先分析理清完單依賴的下游業務，通過趨勢圖和表格多種形式彙總展示。

下游依賴的二級指標拆分完成後，繼續向下追溯，將下游依賴的內部依賴繼續拆分，拆分出 3 層甚至 4 層更細粒度指標，指標繼續拆分下鑽，最底層可能就是各個依賴系統的基礎監控指標 (cpu，mem，load，網絡，宿主機等)。

指標關聯和拓撲建立完成後，就要對指標實行可視化能力，採用的方式多是一些監控大盤和圖表，拓撲圖等形式 (監控大盤建立原則參考監控治理部分)。關聯關係通過線、網、箭頭交織在一起，再根據關聯關係對鏈路流量進行染色，當相關指標發生報警時，就可以根據 trace 串聯出完整的調用鏈路，定位到相關的異常報警和業務影響。

可觀測性監控問題排查過程

當監控具備了可觀測性能力，就可以大大提高問題發現和定位的效率。排查起問題來就會變得像醫生看病，由內到外，由微觀到宏觀，通過 CT 等技術穿透身體各組織，將內外部整體的情況以圖像的方式清晰展現，醫生做出總體的診斷，直達病竈。

1）發現問題

當一級指標發生報警時，就是告訴我們，出問題了，這次以 “下單” 舉例，比如收到了下單耗時增加的預警，開始接手去定位。

2）定位問題

如果一級監控指標下單發生了報警，那麼它依賴的二級指標一定會發生波動。

比如下單的耗時 tp99 升高，觀察下單依賴項，是下單依賴的二級指標 “數據服務” 耗時同期發生波動。

要定位到最終原因，還需收集更多指標信息，繼續下鑽數據服務的下級指標，是應用數據庫中間件 insert 耗時增加，排查後發現超時現象都發生在同一臺服務器，繼續跟蹤該機器基礎指標監控，該機器所在宿主機 load 升高導致，繼續跟蹤，是該宿主機網絡設備出現問題導致。

3）解決問題 (止損)

問題定位後，對問題機器進行下線置換等手段，及時止損，耗時恢復。

4）沉澱預案

問題定位、解決完成之後，期望把處置的經驗沉澱下來，這樣就形成了預案，又多了一項保命符。

故障防禦能力建設

當系統的可觀測性模型越來越細緻，越來越精確，便可以催生出許多自動化，智能化的決策能力，輔助上層做出及時有效的決策，指導我們做精細化的控制，解放人工生產力，這種能力我稱之爲故障防禦能力，如圖：

1）變更防禦策略編排

監控治理完成後，維度覆蓋全面，就會多線上的各項變更納入管控，這裏將變更歸類爲業務類變更和運維類變更，詳細如上圖。針對不同的變更分類，可以指定不同的監控手段來防守，比如運維類的擴容、縮容，不涉及到業務變更，在變更完成後，我們只需要對 OS 指標監控，應用的指標監控進行覈對即可。針對代碼的變更，在發佈部署後，除對基礎的 os 指標，應用指標覈對外，還需要對相關的業務指標進行覈對，以及涉及的資損指標監控。自定義各種編排策略，在不同分類的變更發生時，自動執行對應的監控手段。

2）變更管控

收錄不同分類的變更，自動識別，自動打標，當發生變更時，可以獲悉準確的時間點，自動周知關注人。

3）實時巡檢

對各項基礎設施指標自動化巡檢，及時發現問題，自動周知。

4）主動防禦 (故障自動定位)

當具備了可觀測性，就有了全鏈路的關聯追蹤能力，發生故障時，把相關的變更、告警做分析推導，自動給出根因推薦，還可以對一些核心指標做重保，當重保指標發生報警時及時作出問題推薦，產生處理工單，通過穩定性 AI 智能交互機器人持續跟進，可在釘釘羣一鍵接手，形成處置閉環。對於可自行補償的問題，自動執行補償策略，故障自愈。

5）全域高精可觀測性

所有的智能化決策能力，都是建立在系統高精的可觀測性基礎之上，而可觀測性，又是基於監控，日誌，和全鏈路追蹤三大支柱而來，最終形成無人值守故障防禦能力。

四  寫在最後

最後做一個小結，在雲原生時代，運維自動化和智能化的大趨勢中，系統可觀測性是穩定性建設的最基礎一環，是穩定性保障武器庫中的那把 “霜之哀傷”，完善的可觀測體系可以幫助我們屏蔽系統的複雜性，使系統整體的運行狀態清晰可見，在故障防禦和排查方面發揮了巨大的作用，增強對系統的信心。

穩定性建設又是一個體系化的工程，不可能一蹴而就，關鍵在於持續不斷的完善，更脫離不了業務，高德打車業務的穩定性建設也是在業務不斷髮展過程中逐步探索建立起來，2020 年多個節假日出行高峯向我們提供了最好的 “練兵場”，“試金石”，系統平穩度過。

當然穩定性建設的打法是多種多樣的，但目標都是一致，希望本文對大家有些許幫助。

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

猜你喜歡