編者按：本文源自阿裡雲雲效團隊出品的《阿裡巴巴DevOps實踐指南》，掃描上方二維碼或前往：https://developer.aliyun.com/topic/devops，下載下傳完整版電子書，了解阿裡十年DevOps實踐經驗。
随着雲原生技術的發展與演進，微服務和容器化技術成為大型分布式 IT 架構的必然選擇。新技術在讓 IT 系統變得更靈活、健壯、高性能的同時，也帶來了更高的技術架構複雜度，給應用監控帶來了前所未有的挑戰。
傳統監控挑戰
系統監控爆炸式增長
傳統監控重點關注應用、主機、網絡等系統層面的監控。随着微服務、雲原生等新技術的大量運用，系統架構越來越複雜，應用數量呈爆炸式增長。當一個故障發生時，大量系統報警會産生報警風暴，使得技術人員無法快速定位問題。同時，大量的系統級監控會産生大量誤報，技術人員被迫花費大量的精力去處理這些誤報，最終對報警産生麻木。
監控結果和業務目标之間欠缺聯系
傳統監控缺少業務視角的監控，以及業務與 IT 系統之間的聯系。這導緻使用者、業務人員和技術人員之間無法形成統一視角。很多故障往往是使用者已經回報，技術人員卻在用系統監控名額證明系統沒有問題。或者業務已經受損，技術人員依然無法确定是哪個系統的問題，恢複時間被大大拉長。
監控工具之間資料割裂，資料缺乏分析
以往阿裡巴巴采用多種監控工具，用于監控網絡、實體機、應用、用戶端等不同的對象，但不同工具之間無法共享資料，監控資料缺乏統一的分析，更加難以跟業務場景相結合，造成大量的故障隻能依靠技術人員的經驗，在多個工具之間不斷地切換和逐漸排查，大大增加了故障恢複時長。
監控維護成本高，報警準确率低
傳統監控都需要大量的配置工作，整個過程費事費力，缺乏自動化、智能化監控的手段，這也是造成各系統監控能力參差不齊的重要原因。一些新業務因為無力投入大量精力配置監控，導緻業務監控能力缺失。同時，随着業務的發展，技術人員需要不斷地調整報警規則，又常常因不及時的調整造成誤報和漏報。
業務驅動的監控理念
為了适應 DevOps 研發模式，解決傳統監控的問題，阿裡巴巴總結了一套以業務驅動的自頂向下的全景監控體系，主要包括：業務監控、應用監控和雲資源監控三層：
- 業務監控是整個監控體系的“頂層”，能夠反映使用者使用業務的真實情況，可以與業務結果直接挂鈎，能夠被不同部門、不同角色的人員所了解。
- 應用監控提供應用中服務和系統層監控能力，能夠直接反應系統運作狀态，幫助研發人員全面了解應用中服務和中間件的健康狀态，快速定位系統問題。
- 雲資源監控提供應用依賴的各類雲資源(如 RDS、OSS、SLB 等)的基本監控，在故障排查中能夠為研發人員提供執行個體級别的明細監控資料，快速确定是應用系統的問題，還是雲基礎實施的問題。
監控分層以後，各層的監控名額和報警規則會按重要程度分成嚴重、警告、普通等多個等級，不同層次、不同級别的監控報警會被分派給不同的角色來處理，比如集團的安全生産團隊隻關注全集團的核心業務名額，事業部的穩定性負責人關注部門級的核心業務監控，每個團隊的研發人員則接收自己負責業務和應用報警，而雲資源執行個體的監控一般不發送告警消息，主要用于故障排查和定位。這樣充分發揮了 DevOps 的優勢，傳統模式中少數運維人員成為故障排查瓶頸的問題也得以解決。同時，每個人需要處理的報警數量大幅減少，也解決了在故障發生時因為報警風暴，而将重要的業務監控報警淹沒的問題。
統一的監控架構
基于全景監控的理念，阿裡巴巴探索出了一套統一監控的架構，該架構不追求大一統的監控平台模式，而是采用分層建設，抽象出了雲資源，應用，業務這 3 種監控系統，每種監控都專注發現相關領域的故障發現，再通過統一 CMDB 解決監控中繼資料互相不統一的問題，通過智能算法平台，報警中心和故障平台集中管理事件，故障以及提升準确率。
業務監控
阿裡巴巴“業務監控”采用專為監控自研的日志采集&計算架構，通過頁面配置即可實時提取日志中的監控名額，具有簡單易用、自定義能力強、響應速度快、對業務無侵入等特點；提供了完整的業務監控領域模型，引導使用者完成監控覆寫。
業務監控的領域模型包括：
- 業務域：一個完整的業務或産品稱為“業務域”，如電商的“交易域”、“營銷域”、“支付域”等。
- 業務場景：業務域中的核心業務用例叫做“業務場景”，如交易域的“下單确認”、“建立訂單”等，業務場景是
整個監控模型的核心。
- 業務名額：展現每個業務場景的特有名額，如每分鐘的訂單數量、交易成功率、錯誤碼等。
在業務名額的選擇上，傳統的運維人員喜歡使用窮舉式的手段配上所有可觀測性的名額，各種告警加上，顯得有“安全感”。實際當故障來臨時，滿屏出現名額異常、不斷增加的告警短信，這樣的監控看上去功能強大，實際效果卻适得其反。
通過對阿裡巴巴曆年故障的仔細梳理，阿裡巴巴集團内的核心業務的常見故障（非業務自身邏輯問題）都可以通過流量、時延、錯誤等 3 類名額反應出來，我們稱之為黃金名額：
- 流量 ：業務流量跌零 OR 不正常大幅度上漲下跌，中間件流量如消息提供的服務跌零等，都可能觸發重大故障；
- 延時 ：系統提供的服務 OR 系統依賴的服務，時延突然大幅度飙高，基本都是系統有問題的前兆；
- 錯誤 ：服務傳回錯誤的總數量，系統提供服務 OR 依賴服務的成功率。
業務監控平台提供了“黃金名額”插件，通過單次配置就可以生成一組黃金名額，是目前業務監控使用範圍最廣的名額模型。
業務監控報警直接與故障關聯，對監控資料的品質有很高的要求，同時需要具備很好的靈活性（既滿足不同技術實作的監控需求，又不能對被監控的業務系統造成性能影響）。阿裡巴巴的“業務監控”通過日志作為資料來源，能最大程度地保證業務監控的靈活性，能夠适應幾乎所有的技術棧。日志采集采用了無壓縮增量采集、zero-copy 等技術，降低監控采集對業務系統的性能影響；采用拉模式架構、重試機制、資料齊全度模型保證了資料采集的可靠性和完整性；完全白屏化的配置能力、完善的調試功能，最大程度降低了使用者的配置難度和配置成本。
應用監控
阿裡巴巴應用監控采用标準化群組件化的方式搭建，與阿裡巴巴技術棧相結合，提供常用的系統和中間件層面的監控元件；運維同學無需修改程式代碼，整個監控過程自動化，應用上線、擴容後自動開啟應用監控，無需人為操作，大幅降低了監控的維護成本。
當運維系統執行應用上線、擴容等操作後會将變更資訊寫入到 CMDB，CMDB 會将變更資訊推送到MQ，應用監控平台訂閱 MQ 實時擷取應用的配置變化生成新的監控任務，監控任務下發到指定的目标伺服器（容器）的 Agent 端，Agent 根據任務的配置資訊發送對應的采集請求，從業務應用提供的 Exporter 等 EndPoint 中擷取監控資料，并上傳到監控叢集進行計算和存儲；同時異常檢測子產品也會根據應用配置的變化生成報警檢測任務，從時序資料庫中拉取監控資料進行異常檢測，并将異常事件發送給報警中心。
雲資源監控
阿裡巴巴雲資源監控直接對接阿裡雲平台的“雲監控” API 擷取各類雲資源的名額資料和報警事件，再将這些資料與 CMDB 中應用與雲資源的關系資訊連接配接，最終形成應用視角的雲資源健康狀态視圖，解決了雲基礎設施監控與上層應用監控互相隔離的問題。依托雲平台的監控能力和 CMDB 的資料積累，整個雲資源監控也是自動化完成的，無需使用者人工配置。
智能檢測平台
為了解決報警準确率低、配置維護成本高的問題，阿裡巴巴建設了智能檢測平台，通過 AI 算法精确地發現線上業務和應用的異常，并且在此過程中不需要任何人工配置報警門檻值。針對業務和應用監控資料的不同特點，采取不同的異常檢測政策：
1、 智能基線
業務監控對報警的準确性要求極高，同時資料會随着業務周期不斷波動，高峰和低谷之間資料可能相差幾十倍甚至上百倍。傳統的門檻值或同環比報警往往需要有經驗的運維專家不斷地調整規則，極易引發誤報。對此，阿裡巴巴采用智能基線算法通過曆史趨勢自動學習資料曲線的周期規律。當業務名額超出基線容忍範圍時，就會立即觸發業務報警。為了優化算法對資料的相容性，智能基線算法通過線上預測的功能（即算法對往後一段時間的資料進行逐點預測），完成了對長期曆史規律與近期曆史規律較好地折衷；基于對阿裡巴巴内部大量多樣化業務名額的訓練和專家經驗标注，讓平台對不同類型的業務波動能優雅地在算法中展現出來，算法可以很好地适配資料曲線中的波動毛刺及随業務産生的高低起伏，可一鍵接入各類業務監控資料；算法長期經受各種外部攻擊及爬蟲的内部壓測幹擾的曆練，目前已具備了對幹擾攻擊較好的抵抗能力；算法可以很好的支援秒級與分鐘級計算，無需任何人工監控配置，無需随業務變化對算法進行調參，算法可自己通過對規律的學習适應業務的變化。
2、 應用名額異常檢測
應用監控名額數量衆多，傳統的人工配置門檻值的方式成本極高。企業往往會采用報警模闆的方式對大量應用配置相同的報警門檻值，但由于不同應用系統的差異性較大，很難定義一個準确的門檻值，這就容易産生“小了漏報，大了誤報”的問題。系統名額的場景與業務名額不同，它的周期性更不确定，各個名額的浮動相對來說會比較大且沒有周期特性。針對應用名額的特性，阿裡巴巴又針對性開發了應用名額異常檢測算法，通過斷層檢測、頻率波動異常檢測、尖峰/低谷異常檢測、長期趨勢漸變檢測、浮動門檻值等多種算法聯合進行檢測；同時由于應用監控名額數量衆多，為了能夠大範圍使用，所有檢測方式都采用了輕量化算法，大幅降低異常檢測服務的資源消耗。
報警中心：統一對接各監控平台的報警事件，實作報警事件地統一記錄、統一處理（合并、降噪、抑制等），最後發送到相關處理人。
故障管理平台：用于定義故障等級并管理整個故障生命周期的平台，命中故障等級定義的重要報警将更新成故障，進入故障管理流程。
CMDB: 運維統一 CMDB 是整個阿裡巴巴應用運維體系的中繼資料中心，維護着整個阿裡巴巴的産品、應用、執行個體（容器、VM、雲資源）、機房、單元、環境等運維對象，以及對象之間的關聯關系，各層的監控系統都與 CMDB 模型中的對象關聯。
通過這樣體系化的建設，我們不但能在故障發生時快速準确的發出告警，還具備了從業務入口下鑽分析故障鍊路上各個關鍵應用，資源狀态，甚至基礎設施的能力。是以開發運維人員可以在一個監控界面上逐漸排除故障發生時的可疑點，快速定界到故障發生的原因。
這裡以某訂單系統調用延時突增故障為例，介紹一下全景監控的故障排查過程：
- 線上問題發生的第一時間，負責該訂單系統的研發 Owner 會收到報警中心的調用延時報警（如果線上問題達到故障等級标準，故障台将自動發送對應等級故障通告給相關人員）。
- 研發人員通過報警資訊中的連結直接打開對應業務監控頁面檢視交易總調用量、延時、成功率等黃金名額資料，發現延時大幅升高，成功率有所下降，調用量沒有明細下跌，排除上遊流量徒增造成系統容量問題的情況。
- 通過業務監控的多元下鑽功能，檢視交易的錯誤碼詳情可以發現“逾時錯誤碼”大量增加，可以排除是業務邏輯類問題。
- 繼續從業務監控下鑽到應用監控，根據訂單名額對應的調用鍊路發現，某下單應用的資料庫調用成功率大幅下降，調用延時暴增。
- 再從應用監控下鑽到雲資源監控，檢視該應用關聯的資料庫的 CPU、調用時長、慢 SQL 名額都出現異常，檢視慢 SQL 清單和應用的變更記錄發現與上一次釋出的定時任務相關，通過運維系統復原後解決問題。
監控管理體系
好的監控體系除了有優秀的監控功能以外，還必須有與之配套的管理系統。阿裡巴巴采用了故障管理驅動的監控管理體系，為各個部門、團隊制定了嚴格的量化故障等級定義。故障等級定義直接與業務監控名額關聯，明确不同故障等級對應的名額觸發規則。安全生産團隊會與各業務部門梳理核心業務場景、業務名額和故障等級定義。梳理完成的“業務監控”配置和“故障等級定義”需要通過評審達成一緻，使得業務團隊（營運、産品、客戶）與研發團隊之間形成統一的監控标準，明确各方的職責，降低溝通成本，實作監控結果與業務目标的強關聯。
整個故障定義的過程都是線上化和結構化的，當業務名額超出故障定義的範圍時，故障台會自動觸發故障通告，并将通告資訊及時發送給相關團隊的技術人員。技術人員通過故障通告快速檢視業務監控資料，通過全景監控的縱向拓撲關聯能力，從業務名額下鑽分析到關聯應用狀态，再從應用狀态下鑽分析到雲資源狀态，實作快速故障定位。然後技術人員根據故障排查的資訊，确定故障恢複方案，并通過運維平台執行復原、降級、切流等操作快速恢複故障。整個過程都線上上完成，故障排查的進展會自動推送給相關人員，所有操作都會被記錄。最後由安全生産團隊組織故障複盤，制定改進措施、完善監控覆寫，實作業務安全生産的正向回報。
總結
全景監控不僅是業務、應用、資源等分層監控能力的簡單內建，更重要的是具備通過業務名額下鑽分析到應用狀态，及從應用狀态下鑽分析到資源狀态的縱向拓撲關聯能力，也是各層名額的智能化健康檢查能力的一體化監控。全景監控直擊傳統監控平台缺失業務監控能力、各層監控資料及報警分散、監控配置成本較高等痛點，基于阿裡巴巴強大的監控技術積累和應急故障處理的最佳實踐，為阿裡巴巴經濟體提供一體化、一站式的監控解決方案，是阿裡巴巴安全生産管理的最佳實踐。
【關于雲效】
雲效，雲原生時代一站式BizDevOps平台，支援公共雲、專有雲和混合雲多種部署形态，通過雲原生新技術和研發新模式，助力創新創業和數字化轉型企業快速實作研發靈活群組織靈活，打造“雙敏”組織，實作 10 倍效能提升。
立即體驗