業務驅動的全景監控體系在阿里的應用 | 阿里巴巴DevOps實踐指南
編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，掃描上方二維碼或前往：//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 倍效能提升。
