作者 | 京廊
來源 | 阿裡技術公衆号
一 寫在前面
網際網路工程的高速發展，分布式、微服務、容器化架構的流行，網際網路已全面進入雲原生時代。建構系統的方式由最初的單體大應用演變為分布式架構，一台伺服器可能僅存幾小時甚至幾分鐘，這種複雜性大大增加了把系統運作狀态可視化的難度。
高德打車業務的發展曆程也不例外，同樣經曆了從單體大應用到服務化拆分的過程，龐大的應用體系和架構的不斷更新，保障了多個節假日出行高峰的穩定，業務仍在持續快速的發展中，如何保障這套龐大又複雜的系統持續高性能、高可用、高可控？建構360度無死角的多元度可觀測能力顯得愈發重要。
二 談系統可觀測性
1 什麼是系統可觀測性
可觀測性(observerbality)，是一個最近幾年開始在監控社群流行起來的術語，可觀測性的提出最早來自于 Google 著名的 SRE 體系和 Apple 工程師 Cindy Sridharan 的博文《Monitoring and Oberservability》，感興趣的同學可以看一下。
可觀測性不是一種具體的工具或技術，更偏向于是一種理念，目前已成為複雜分布式系統成功管理的關鍵組成部分，它是指運作中的系統可被調試的能力，這種可調試能力的核心就是能夠在系統運作時對其了解、詢問、探查和排程。
了解，詢問，探查展現在幫助工程師發現問題 -> 定位問題 -> 解決問題(止損)，排程展現在可根據系統運作狀态做出的自動化，智能化決策的能力。
可觀測性的目标是增強工程師對系統運作狀況的了解，增強對系統的信心。
目前，業界廣泛推行的可觀測性包含三大支柱：日志事件(Logging)，分布式鍊路追蹤(Tracing) 和 名額監控(Metrics）。
- Logging：不能單純的了解就是日志，泛指的是應用運作而産生的可以詳細解釋系統運作狀态的各種事件，日志記錄是其中最常用一種手段。
- Tracing：全鍊路追蹤，面向的是請求，通過對請求打标、透傳、串聯，最終可以還原出一次完整的請求，可幫助工程師分析出請求中的各種異常點。
- Metrics：是對Logging事件的聚合，泛指各種名額監控和大盤，通過多元度聚合、分析和可視化展示，幫助工程師快速了解系統的運作狀态。
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(...) ，而是指專用于定位業務問題，根據自己的業務特點，經過認真規劃，打出的需要統一收集、存儲和分析的業務相關的日志。
含關鍵資訊，非關鍵資訊，附加資訊：
關鍵資訊是業務流程中的重要辨別，一般會建立查詢索引，比如高德打車的訂單ID,使用者ID等。
非關鍵資訊一般為業務日志描述，如“使用者下單成功”，非關鍵資訊可不建索引。
附加資訊一般為業務流程中的附加資訊，如“訂單狀态”，“訂單标記”等，可不建索引。
錯誤日志
錯誤日志也進行格式統一，友善對異常的全鍊路分析和追蹤。格式舉例如下，如果某一項沒有資料，會使用'-'進行占位。
2 全鍊路追蹤
分布式全鍊路追蹤(Tracing)是可觀測性的第二大支柱，全局唯一的TraceId利用阿裡中間件鷹眼Id的現成解決方案實作，保證了在整個鍊路的唯一性，然後解決掉在分布式調用鍊路中，同步改異步丢失traceId的問題，該traceId會同時在監控日志，服務日志，和錯誤日志以及其他日志中透傳并記錄，traceId持續的傳下去，就是給整個請求鍊路打上了标記，鍊路上涉及的所有應用日志收錄到阿裡雲SLS，接入阿裡雲api，通過api拿到所有應用的日志，通過TraceId就可以還原這次請求的整個上下文。
市面上有很多 APM 廠商，監控社群也有很多開源的鍊路追蹤系統均可采用。
3 監控治理
這一階段我傾向于稱作是對可觀測系統第三大支柱(Metrics) 的實作，是監控的梳理、補全優化階段。“巧婦難為無米之炊”，如果基礎監控項都覆寫不全，何談可觀測性。
這裡我把監控歸類為5個領域，如圖：
醒一下，監控體系建設沒有銀彈，任何值得解決的事情都需要為之付出努力，不要幻想有一種工具能一下子解決你所有的監控問題。
再提一個監控建設的反模式“勾選式”監控。就是按照各種文檔和要求，把各種監控工具都用上，然後就開始自嗨的認為自己的系統就會健壯無比，高枕無憂，這就是典型的“勾選式”監控，為了使用而使用，不會有好的效果。
分類介紹下上圖監控體系的5個領域：
基礎設施監控
首先是對于機器和作業系統環境的各項基礎名額監控：cpu，mem，load，io，磁盤等，相信任何一個成熟的監控平台都會具備這項基礎能力，不再贅述。
中間件監控
各種中間件的使用是分布式系統的重要元素，對于中間件的監控要遵循各個中間件的監控規範，推薦使用中間件自己的日志，名額模闆等，不必重複造輪，口徑統一也會減少溝通成本。
應用&業務監控
應用監控統一歸納為請求量，耗時，成功率三類，稱為三大黃金名額：
- 請求量，含QPS、TPS、QPM、TPM等，其中分鐘級名額必備，秒級名額在核心鍊路中也是必備，秒級名額可以探查到瞬時流量洪峰，在核心鍊路中是需要重點關注的。
- 耗時，不能隻是平均耗時，還有要TP99，max等，平均耗時更多的是反應一個趨勢，開發人員必須要關注TP99，隻看平均耗時會隐藏掉諸如毛刺等很多問題。
- 成功率，包含接口成功率和業務成功率，接口成功率即請求該接口正常傳回即認為成功，反映的是請求鍊路的問題。業務成功率是該接口的業務邏輯成功失敗，反映的是業務的正确性，這是兩個完全不同的名額。錯誤日志的監控，在此也歸類到成功率的監控中，也是一個不可或缺的重要名額。
将應用監控的各項名額進行統一，一方面可以友善的查漏補缺，按照應用和接口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年多個節假日出行高峰向我們提供了最好的“練兵場”，“試金石”，系統平穩度過。
當然穩定性建設的打法是多種多樣的，但目标都是一緻，希望本文對大家有些許幫助。
2021阿裡雲峰會暨開發者大會
親愛的開發者，阿裡雲開發者大會5月29就要在北京國家會議中心開幕啦！我們邀請了網際網路大咖、技術大佬們和大家一起聊聊技術，聊聊開發者的未來…我們非常誠摯的邀請你參與這次大會。
點選這裡，即可報名，期待你如期趕赴江湖之約！