蘇寧11·11：Monitor在左，Control在右，監與控的結合——深度剖析穆加決策分析平臺
撰稿：朱健榮
策劃：Natalie
作者介紹
朱健榮，蘇寧雲商 IT 總部資深中介軟體技術專家，主要負責應用系統監控的整體解決方案。研發的中介軟體應用系統經歷了蘇寧 818、雙 11 等購物狂歡節的嚴苛考驗，真正具備低延遲、高併發、高可用、高可靠，可支撐萬億級的資料洪峰。深知系統的穩定性對電商平臺的重要性，現在正和研發團隊一起建設應用系統監控層整體解決方案，已研發出服務端和呼叫鏈監控、智慧警告和決策分析平臺。始終秉承工匠精神，精益求精，持續優化使用者體驗、提神技術實力，力爭做出更好的產品。
一、背景
在當今網際網路時代，企業大都採用分散式系統設計和微服務化，內部關係錯綜複雜，各產品分散，整合度不高。雖有眾多日誌監控工具，但沒有全鏈路監控，定位問題及根因分析耗時長。同時由於缺乏決策並自動控制（自愈）機制，基本靠人工來排查處理，面對大規模高併發的場景時，對資料中心的效能、安全、穩定性影響缺乏量化，合理性規劃時也很難兼顧效能與穩定性、可用性。
此前蘇寧已有穆加服務端效能監控（以下簡稱 Baymax）、穆加呼叫鏈監控（以下簡稱 HIRO）等產品，但這僅僅是在“監”的層面上去主動發現系統出現的一些問題，而沒有對解決這些問題做出“控”的動作。基於此，我們研發了穆加決策分析平臺（以下簡稱 ZEUS），它將打通蘇寧內部所有的監控渠道，真正意義上使得監控系統具備“控”的能力，通過與運維繫統聯動，達到系統問題自愈的效果，實現“監”與“控”完美結合。
二、關於穆加
穆加是蘇寧資料雲公司中介軟體研發中心自研的端到端系統監控的產品線名稱。目前中介軟體研發中心有四款穆加旗下的產品已經上線並提供服務，分別是：Baymax、HIRO、穆加智慧告警平臺（以下簡稱 APOLLO）以及 ZEUS，如圖 2.1 所示：
圖 2.1
三、ZEUS 剖析
什麼是決策分析
決策分析就是用海量的資料來支援決策。這些資料包括歷史記錄中的和實時產生的，通過大資料分析、系統的規則匹配及自主學習，將資料轉化為使用者可讀的決策資訊，從而減輕了使用者從事低層次資訊處理和分析的負擔，提高了決策的質量和效率。
ZEUS 介紹
ZEUS 基於監控系統採集的原始監控資料，使用 CEP 做聚合計算、Drools 做規則判斷，將監控資料按照系統及時間維度統合後，能夠為使用者提示監控資料背後可能引起問題的根因，縮短問題定位的時間。主要特點如下：
1) 基於蘇寧系統執行時與 IDC 環境建模構建的規則引擎庫，同時支援使用者自主分析並手工新增規則
2) 精確定位，秒級響應，快速解除問題，降低人工剖析問題的時間，由系統智慧分析並提供決策
3) 提供系統畫像、資源管控、大促投屏等功能，讓使用者可以實時、全方位、全天候感知自己系統的健康狀況，並給大促提供全息監控檢視
4) 靈活擴充套件分析能力，開放平臺介面，實時訪問資料，無縫對接第三方系統
5) 與蘇寧內部的 IaaS/PaaS 以及運維管理平臺聯動，進行自動擴縮容和故障處理
6) 支援 SaaS 公有云和私有化部署
ZEUS 架構
ZEUS 架構分為六層，從上到下依次是源資料層、資料接入層、決策分析層、資料儲存層、Portal 層以及對外輸出層。如圖 3.3.1 所示：
圖 3.3.1
1) 源資料層：決策分析平臺的資料來源。目前接入的資料有 Baymax、HIRO、主機、釋出事件、CDN 和移動 APP。隨著源資料越來越豐富，平臺的決策分析也將更精準。後期我們將全面接入使用者畫像、後端系統、IDC 及基礎平臺、業務全息資訊等資料來源，實現基於全息監控的決策分析，如圖 3.3.2：
圖 3.3.2
2) 資料接入層：負責把源資料接收到決策分析平臺。目前有實時和離線兩種接入方式，分別應對不同的場景需求。
3) 決策分析層：負責實時和離線的決策分析功能，是整個平臺的核心。實時分析通過對流式資料進行即刻和短時匯聚分析，從而實現實時決策；離線分析可以實現對時間跨度比較長的資料進行分析，匹配出符合使用者自定義規則、專家規則和機器學習規則的決策事件。機器學習目前採用的是監督式學習，樣本資料來自專家系統和使用者反饋資料。
4) 資料儲存層：用於儲存原始資料和處理後的資料。目前原始資料主要儲存在 HDFS，處理後的資料按業務特性分別儲存在 HBase、Hive、Druid 和 MySQL 中。
5) Portal 層：負責資料展示和互動。使用者可以通過 Portal 進行配置規則、檢視決策事件和問題反饋原因，也可以檢視系統的健康狀況。圖 3.3.3 和圖 3.3.4 分別展示了系統健康狀況和根因分析：
圖 3.3.3
圖 3.3.4
6) 對外輸出層：負責決策分析平臺的對外輸出。目前主要是將決策事件傳送告警平臺、大促期間的統一監控平臺以及 CD、PCP、ITSM 等平臺。
核心流程
ZEUS 整體處理流程如下：
- 平臺接收來自各平臺如 Baymax、HIRO、Zabbix 等監控源資料，通過 CEP 進行事件的聚合和分析
- CEP 處理後的事件，進入規則引擎，進行規則判斷推算出發生異常的根本原因或決斷出接下來採取什麼動作 / 決策。規則轉化的處理如下：將業務語言轉換成 EPL（CEP 引擎能處理的語言）檔案和 drl（規則引擎 Drools 能處理的語言）檔案。
生成 EPL 檔案和 drl 檔案的步驟如下：
- 管理員在後臺錄入 metric
- 管理員在後臺頁面錄入業務規則，業務規則需要與 metric 關聯
- 後臺將規則轉換成 EPL 檔案和 drl 檔案，存入資料庫並寫入 Zookeeper舉例說明，使用者在頁面錄入的規則如下：
後臺翻譯後的 EPL 檔案和 drl 檔案分別如下：
epl.xml：
rule.drl：
- 最終的分析結果落入 HDFS
- 將 HDFS 中的分析結果進行聚合，計算出最終結果，展示給使用者或通過 APOLLO 進行告警，如圖 3.4.1 所示：
圖 3.4.1
決策分析層分為實時處理和離線處理，其流程分別為：
實時分析處理流程
圖 3.4.2
主要功能：
1) 對系統層、業務層、主機層進行實時監控
2) 通過實時處理平臺，從簡單事件流資料中匹配出符合規則的複雜事件
資料處理流程：
1) 監控資料作為簡單事件流進入實時處理平臺
2) CEP 引擎對多個簡單事件流進行識別、規則匹配生成最終符合特定規則的複雜事件資料
3) 通過最終生成的複雜事件資料甄別出業務系統可能存在的問題，並根據甄別出的資料給出決策（在對問題事件進行甄別時所有指標基線都來自歷史基線資料，歷史基線資料由相關資料模型定期學習更新）
離線分析處理流程
圖 3.4.3
主要功能：
1) 生成各個維度不同時間粒度的統計報表，可進行縱向和橫向的指標對比
2) 根據統計計算規則，生成不同指標的臨界閾值，用於輔助實時決策判斷
3) 根據統計結果，找到各類資料不同指標的統計異常點，結合使用者問題描述，給出指標值與問題的關係，並輸出為描述規則，該規則可用於問題的自動判斷和預測
4) 利用機器學習的迴歸、分類等演算法，對資料進行訓練學習，生成迴歸、分類等模型，利用此模型可對新的資料進行分類、預測，從而實現問題的自動判斷和定位
資料處理流程：
1) 所有外部資料統一接入 Kafka 訊息佇列
2) 通過 Flume 將資料收集到 HDFS 檔案系統
3) 使用 Spark 對原始檔案進行預處理後儲存在 HDFS/Hive 中，該資料將長期儲存，用於應對歷史資料分析
4) 使用 Spark 對儲存在 HDFS/Hive 的資料進行各類統計分析，使用機器學習演算法對資料進行訓練學習，生成分類、預測模型，統計分析和機器學習結果根據需要分別儲存到 MySQL 和 Druid 中
5) 利用 Druid 提供的各種查詢統計功能（時間序列、聚合、上卷下切、關聯等）對 Spark 分析出來的資料進行二次分析
技術難點
在設計和開發過程中，遇到很多難點，其中最具有代表性的有：
- 資料關聯儲存：當資料種類較多時，需要將各類資料關聯起來進行統一分析，才更容易發現問題的原因，如何有機的關聯各種資料，同時如何有效的儲存這些資料才能方便應用展示也有相當的難度。對策：從不同的維度對資料進行整合，比如從系統維度、使用者維度、主機維度、統計指標維度等，將某一維度屬於同一物件的資料進行整合集中儲存，不同維度的資料可以分別儲存，使用不同的儲存方案。既可以從不同維度進行資料分析，還能有效降低上層應用獲取並展示資料的複雜性。
- 規則複雜性：對於有些問題，需要由多個條件組合的複雜規則才能判斷，當條件較多、組合方式較多時，實現的複雜性會大大增加。對策：實現一套靈活的規則定義邏輯，能有效的將使用者的業務規則定義成程式可以理解的規則。
- 規則提煉：如何能夠提煉出有價值的判斷規則，能根據實際問題自動生成規則，或者調整現有規則的一些閾值。對策：結合統計方法和機器學習演算法，對歷史資料進行分析挖掘，結合使用者處理問題的經驗，提煉出有價值的規則，並計算出合適的閾值。
規則定義例項說明
定義一套靈活的規則，關鍵要明確該套規則應用的問題場景，要點在於收集系統應用層、服務層、主機層等系統各方面產生的實時特徵資料，包括相互關係、型別、數值、產生時間等資訊，從特徵資料中提取出判斷指標以及對應的閾值。
ZEUS 規則定義邏輯如下：
1) 約定規則定義因子：指標集 (指標來源)、指標、統計函式（avg、sum、count、max、min、tp、variance）、關係運算符 (>、<、=、!=、>=、<=、in、between)、閾值、邏輯運算子 (&&、||、!) 等
2) 定義規則時，可以通過指標集、指標、統計函式、關係運算符、閾值組合出基本規則表示式
3) 基本規則表示式可以通過邏輯運算子與其它規則表示式繼續組合，也可以與其它規則表示式的巢狀進而形成結構靈活、邏輯完善、功能更強的複雜規則
規則儲存為 json 格式，通過規則解析模組翻譯處理後載入規則處理引擎。
當實時處理模組中的規則處理引擎處理資料命中某條規則時，則可以根據該規則精準判斷出問題場景、產生的原因並給出相應解決建議。
例如，某次大促活動期間監控大盤顯示某核心系統響應耗時統計超過正常重新整理時間資料仍然不變，經過排查是由於該核心系統所在主機上的另一系統在該時間段上流量過大，搶佔了該主機的網路頻寬，導致該核心系統網路延遲，同時通過 ping 測試該段時間丟包嚴重，某 RPC 服務介面頻繁連線超時。我們可以按照如下思路定義該場景的規則：
1) 定義響應耗時規則：單位時間內某 PRC 服務介面響應耗時超時次數>n
2) 定義網絡卡流量規則：單位時間內網絡卡平均流量>m
3) 定義 ping 丟包規則：單位時間內的網路丟包率>p
4) 定義組合規則: (單位時間內響應耗時超時次數>n)&&(單位時間內網絡卡平均流量>m) &&(單位時間內的網路丟包率>p)
由此，規則定義結束並提交到實時處理模組。如果實時處理模組命中該規則，觸發系統告警提示，就可以推測出某程式大量佔用網路頻寬，造成網路負載較重，進而造成服務響應超時，無法正常提供服務。
四、遠景規劃
在今年的雙 11 大促中，ZEUS 已經在蘇寧展示了其強大的功能——聯合 Baymax、HIRO、APOLLO 等產品組成一個封閉的監控生態圈，實現了“監”與“控”的結合，為各業務系統的穩定執行提供了強有力的保障。
ZEUS 的未來規劃如下：
- 豐富產品功能，新增如使用者反饋、問題回演、問題分析歸納等功能，從多維度剖析問題根因
- 深度利用機器學習、深度學習以及自然語言處理，實現決策判斷的真正智慧化，降低對專家系統的依賴，以適應更多複雜場景
- 提升系統的開放程度，形成開放平臺，提供決策分析結果的同時共享原始資料，與其它系統共同挖掘資料中隱含的價值
原文來自微信公眾號：高效開發運維