背景
近年來，随着阿裡新業務、新技術的快速發展，傳統的業務總量“監控大盤”已經越來越不能滿足監控需求，主要表現在以下幾個方面：
缺乏全局視角：“監控大盤”主要反映的是單個業務或應用的運作狀态，缺少全局的業務視角能反應整個“業務域”的上下遊整體的運作情況。比如交易系統成功率下跌，想看看是不是優惠出問題了，但是不知道“優惠”的業務監控在哪裡，隻能依賴"優惠"的同學去排查，釘釘電話溝通，大家一起拼湊資訊，上下遊協調成本很高。
監控标準不統一：一直以來“業務監控”都是自定義的，依賴開發人員的個人經驗，往往系統、業務監控混在一起，沒有标準，業務之間不能比較；各系統監控能力參差不齊，很容易出現業務鍊路中的監控斷層；業務監控缺少一套行之有效的方法論，新人或者新業務對于業務要怎麼監控，不知道如何下手、不知道自己配的監控是否覆寫全面，隻有等到故障發生以後才去補監控。
缺少業務視角：随着阿裡業務飛速發展，特别是“大中台”的建設，使得傳統的“總量”監控已經不能滿足需求，比如一個“交易”中台業務就會有數十個“業務方”調用，單純的總量監控會把小調用量的業務淹沒，必須按每個業務方的“業務身份”進行監控。對于像“盒馬”、“淘鮮達”這樣的新零售業務，這樣的問題更加突出，一家門店出現交易異常對于“交易總量”來說是微不足道的，但是對這件門店的客戶體驗來說是災難性的。
監控配置成本高：“業務監控”一直都是由“開發人員”純手工打造，需要經過日志埋點、監控配置、報警門檻值設定，整個過程費時費力，缺乏自動化、智能化監控的手段，這也是造成各系統監控能力參差不齊的重要原因，一些新業務因為無力投入大量精力配置監控，導緻業務監控能力缺失。
全景式監控
業務全鍊路監控從業務的視角出發，監控整個業務流程的健康狀況，無需多個系統切換，直覺看到全局和上下遊，友善快速發現、定位問題。
建立了完整的“業務監控模型”，為業務建立起一個從“宏觀”到“微觀”的全景式業務監控體系，結束了業務監控沒有标準，隻能純手工打造的曆史。業務監控模型主要包括3部分：
● 業務域：一個完整的業務或産品稱為“業務域”，如電商的“交易域”、“營銷域”、“支付域”等。
● 業務活動：業務域中的的核心業務用例叫做“業務活動”，如交易域的“下單确認”、“建立訂單”等，業務活動是整個監控模型的核心，每個業務活動都會有标準的【黃金名額】來反應自身的健康狀況，業務活動之間建立上下遊關系就形成了業務鍊路。
● 系統服務：業務活動中的依賴的關鍵方法稱作“系統服務”，如“下單确認”包含：查詢會員、查詢商品、查詢優惠等關鍵方法，每個系統服務也通過【黃金名額】來表示其健康狀況。
監控流程
以“監控模型”為基礎，我們總結出了一套如何做好“業務監控”的方法論，并将其沉澱到産品中。
● 梳理關鍵業務： 業務方需要梳理出自己的核心業務是什麼（業務活動），以及這些核心業務的關鍵依賴有哪些（系統服務）。
● 監控資料埋點：提供了無侵入的配置化監控SDK，隻要将“業務活動”和“系統服務”對應的方法填寫到配置檔案中即可，系統會自動收集，計算，上報監控資料。
● 監控鍊路：系統根據收集的資料自動生成業務鍊路，每個“業務活動”和“系統服務”節點都自動生成流量、耗時、成功率的黃金名額，同時每個‘節點’都可以通過鑽取檢視詳細的監控資料，包括：不同機房、單元、分組的資料對比，每個業務身份的明細調用情況等。
● 異常檢測：業務鍊路涉及節點衆多，必須要有完善的異常檢測機制來幫助使用者自動發現問題，我們提供了“智能基線預警”和“專家規則預警”相結合的異常檢測機制，無需使用者逐個配置報警規則，自動發現異常節點，實時将這些節點“标紅”，異常的詳細資訊也會同步顯示，友善使用者快速發現和定位問題。
通過業務全鍊路監控，可以做到對業務域的監控标準化和全覆寫，避免了自定義監控覆寫不全面、不标準、配置工作量大的問題，使得老闆、PD、營運、監控值班等使用者都可以快速了解業務是否有問題。
黃金名額
引入Google的黃金名額概念，改變了業務監控完全依賴自定義的現狀，為業務監控樹立了标準。
● 流量 ：業務在機關時間内的調用量，如：服務的QPS、每秒訂單筆數等。
● 耗時 ：業務的具體處理時長，需區分成功耗時和失敗耗時。
● 錯誤 ：調用出錯數量、成功率、錯誤碼。
● 飽和度 ：應用已使用資源的占比。
由于飽和度更多反應的是應用的層面情況，是以業務監控使用流量、耗時、錯誤這三個名額就能很好的回答“業務”是否健康的問題，在“業務全鍊路監控”中每個業務活動和系統服務都會标配這三個監控名額。
除了黃金名額以外，還可以根據各自業務的不同特點，定義各種分次元的輔助名額，比如：按不同的業務身份，按商家、按門店分，不同的錯誤碼等等，用于進一步細化和定位
業務次元
傳統的“總量”名額已經不能滿足中台、盒馬這樣的業務監控需求了，通過可擴充的業務次元實作對業務身份、商家、門店的精細化監控。像“交易”這樣的中台業務會被幾十個業務方調用，總量沒有異常并不代表具體的業務方沒有問題，而是需要監控每一個業務方各自的調用情況，隻要有一個出現異常就要預警。
橫向業務次元：業務全鍊路監控提供了“橫向業務次元”功能，能夠友善的配置“業務身份”、“商家”、“門店”等特定的業務次元，可以對一個業務域中所有的“業務活動”和“系統服務”按一個次元過濾，比如可以對交易鍊路按“盒馬”這個業務身份過濾，進而在鍊路上看到的是盒馬的交易調用情況。
配置化埋點
監控SDK使用AOP切面技術實作了配置化埋點能力，業務系統引入監控SDK後，通過簡單的一個配置檔案即可完成監控埋點，自動完成資料的攔截、計算、上報，與業務代碼完全解耦。
鍊路自動生成
自動生成應用核心鍊路、黃金名額、業務次元大盤，無需使用者配置，使用者還可以通過可視化編輯頁面對鍊路進行調整。
智能基線預警
通過機器學習快速預測名額的合理範圍，一旦超出邊界就會自動觸發報警，無需配置門檻值。
智能基線預警已經在業務自定義監控中得到了驗證（已經有超過1200名額接入），準确率和召回率相對于人工配置都有大幅提高，現在我們将該技術引入“業務全鍊路監控”，實作對業務活動的智能異常檢測，全程無人參與。
實戰
實戰1-交易全局鍊路
交易域的全局業務鍊路，鍊路中列出交易的關鍵“業務活動”，省略了每個業務活動的“系統服務”等細節，主要用于全鍊路壓測，大促投屏等需要關注全局狀态的業務場景，已在6.18大促中得到實際應用。
實戰2-交易核心鍊路
交易是整個電商的核心，我們通過“鍊路自動生成”能力生成了核心業務鍊路，其中綠色節點為“業務活動”，黃色節點為“業務活動”依賴的“系統服務”。
通過業務鍊路可以很友善了解交易活動的運作狀況，一旦業務活動出現問題也可以更加直覺的發現與下遊依賴的關系。
實戰3-POS服務端鍊路
POS是整個新零售場景線下支付場景的交易核心，下線支付場景對交易系統提出更加嚴格的可靠性要求，通過POS業務鍊路可以很好的監控POS交易各環節的運作情況，及時發現交易異常。
同時POS鍊路添加了“商家”、“門店”的業務次元，可以實時切換“盒馬”，“大潤發”等不同商家的POS交易情況，實作針對每個商家精細化監控。
原文釋出時間為：2018-08-27
本文作者：勁節
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。