【51CTO.com原創稿件】在高效地支撐蘇寧互聯網相關業務的過程中，各系統間的交互也變得如圖 1 一樣錯綜復雜，下圖中的點代表各個應用系統，連線代表系統間的交互。

[[242738]]

圖 1：系統交互圖

以上錯綜復雜的特性主要由以下兩個原因導致：

• 系統和服務的復雜性：體系數量龐大：4000+ 系統，10w+ 服務；系統間調用方式復雜：大部分使用 RSF，也有其他的方式，如 HESSIAN，ESB等。
• 業務的復雜：既有線上新業務又有線下老業務，這些業務系統之間會有大量的關聯。

基礎環境的復雜性：多數據中心，每個數據中心會劃分多個邏輯機房和部署環境；一個系統服務器規模往往會很大，例如，緩存服務器就可能有上千臺。

為解決上述復雜性問題和更加有效的支撐整個業務的發展，我們提出了立體式監控解決方案。

所謂立體式監控，是由傳統的單點系統監控演化而來，在復用當前監控探針的前提下，由單點發展為對業務全鏈路的監控。

并根據采集而來的監控數據進行多維度、甚至任意維度的分析，實現多維空間的監控，便于快速預判和定位系統或者業務故障，提升業務支撐效率。

監控體系建設

蘇寧監控一體化解決方案旨在為用戶提供從系統監控、問題定位、實時告警到決策分析、故障自愈的一站式解決方案。即全力為用戶打造從“監”到“控”的全方位一體化 APM/CPM 解決方案。

從移動 App、PC/WAP端、網絡端、服務端、調用鏈各個級別進行應用性能分析。

能夠深入到應用、數據庫自動捕獲應用性能異常，自動識別有問題的應用組件和代碼，利用關鍵業務性能剖析進行故障原因深度分析，非 IT 專家也能夠快速定位問題原因所在。

采用新一代的應用監控技術，將企業數據中心基礎資源監測數據、用戶體驗監測數據、應用代碼性能分析數據、網絡性能數據、系統運行日志等各類異構、海量的 IT 監測數據進行集中收集和處理，融合蘇寧大數據能力，構建更加高效、更加智能的 IT 故障分析能力。

立體式監控體系整體架構圖如圖 2 所示：

圖 2：蘇寧立體式監控概覽

第一個維度

從左到右，是從監控的思路進行構建的：

• 左邊一塊為監測產品，主要用來發現問題。
• 問題發送給智能告警平臺和決策分析平臺，定位問題根源，反饋給研發團隊及時進行處理，以及服務治理系統進行治理。
• 右邊是自動化的干預處理，最后再回到最左的流程中進行監測。

第二個維度

從上到下，從前端到后端。我們現在的監控主要面對的是蘇寧一些核心應用，比如蘇寧易購手機端、蘇寧金融易付寶等等。

這些應用用戶數量多、范圍廣、使用頻次高，會不斷地反饋應用或服務的問題。

先從用戶角度，對用戶體驗進行監控，一旦發現問題，會立刻針對數據進行溯源，到客戶端通過 SDK 或 JS 抓取一些傳統標準做法采集數據，再通過多維度分析，將數據問題反饋給研發。

同時我們會對服務端進行性能監控，前面也說服務端的系統相對而言要復雜得多，因此我們往往會想辦法串起前后端，做到分鐘級甚至秒級調用，所以我們對調用鏈也進行了監控。

而調用鏈監控依然是在中間件層面，也可能是基礎設置的波動導致了問題的產生，所以在底層對基礎設施構建了監控。

第三個維度

從數據層面：

• 首先是 Metric 指標，這個指標可以是從基礎設施而來的，可以是業務層面定義的，也可以來自性能監控，這是評估性能的一個重要指標。
• 還有一個是 Event 事件，日志監控承載了非常重要的能力，事件幫助系統定位問題。
• 第三個指標 Trace，來源于調用鏈。三個指標會產生交集，輔助定位、排查問題。

根據目前監控體系的現狀，為了滿足日益復雜的監控需求，打造基于 AI 的監控體系，實現面向用戶體驗的無人化智能服務解決方案目標，我們提出了面向現代監控的體系規劃。

詳細的規劃如圖 3 所示：

圖 3：面向現代監控的體系規劃

在該體系中，通過引入自然語言處理、建立知識圖譜和圖像識別等 AI 技術，讓監控實現無人值守，用戶可以更簡單便利地與監控系統機器人進行交互，獲取所需的監控信息。

在問題分析和決策領域，將通過建立計算模型生成不同維度的指標，實現多維度的關聯分析和異常檢測，并且動態計算出告警閾值，生成告警事件推送給用戶。

監控技術實現

監控產品介紹

立體式監控體系由一系列的監控產品構成，每種監控產品都存在獨特的特性，但同時也和其他產品有著相互協調的關聯關系，從而形成一個監控生態體系。

監控主要產品如圖 4 所示：

圖 4：監控體系主要產品及其關系

用戶體驗監控(UOM)

UOM 是一個可以對用戶產品端進行全方位、多種維度進行監控和分析的平臺。

通過將監控采集 SDK 無侵入或者較少侵入的植入用戶端中，獲取用戶在使用產品時對用戶造成體驗影響的調用鏈異常數據，并基于此進行分析、預測和告知該產品的相關運維人員。

通過采用無侵入和較少侵入的方式，將采集 SDK 植入用戶應用，實現對用戶應用的系統異常、業務異常、用戶信息進行采集。

對異常數據進行建模，形成相應的異常數據趨勢圖和用戶軌跡，實現迅速地對用戶應用問題進行定位。

通過態勢感知計算模型動態計算異常增長率，根據不同維度的規則配置，實現對應用異常問題進行告警。

UOM 機器人可滿足用戶在豆芽中，通過自然語言方式直接和機器人交流，實現快速獲取問題根本原因。

圖 5：UOM 系統技術架構

日志統計分析

離線日志統計分析是運用大數據技術，海量歷史日志分析的一種解決方案。專注于幫助使用者發現并解決系統性能問題。

通過分析各類訪問日志，得到各系統使用過程中請求量、響應時間、錯誤率、命中率等性能指標，可以通過分析來源 IP 判斷是否遭受攻擊等。

圖 6：離線分析

實時日志統計分析是一個在 E(Elasticsearch)F(Flume)K(Kibana4)的基礎上進行二次開發的平臺。

它集成了蘇寧內部的賬號體系和系統基礎數據，實現準實時日志的檢索、統計分析。

圖 7：實時分析

調用鏈監控

完全采用 OpenTracing 標準，對系統異常和業務異常進行全鏈路監控。采用字節碼技術實現監控 SDK 植入，對業務系統功能不會造成影響。同時提供及時關閉、自動升級功能，節省人工、降低風險。

并可以應用于各領域應用系統服務和調用鏈監控，為 IT 研發人員檢測系統健康、定位解決問題提供可靠依據。

根據異常棧詳情，用戶可以直觀了解到操作的頁面軌跡以及服務端系統的調用鏈路。

系統利用機器學習分析異常數據并做出預判，提供一站式的預警、排查、告警和問題解決策略。

圖 8：調用鏈監控模塊

監控組件介紹

通過之前的介紹，我們了解了很多目前蘇寧監控體系中的產品，這些監控產品如何無侵入式的植入各個應用中，如何實現對監控數據的采集，請參考圖 9。

圖 9：無侵入式數據采集

具體過程如下：

• 通過字節碼攔截請求，創建調用上下文、生成埋點。
• 調用上下文保存在 ThreadLocal，對應用透明。
• 調用上下文包含了 TraceId、RpcId、調用類型等數據。
• 調用上下文隨著 Http 調用在網絡間傳輸。

“源頭型”：生成 TraceId，創建調用鏈，結束調用鏈。

“單項型”：僅客戶端，生成日志(服務端未埋點)。

“雙向型”：客戶端+服務端，傳輸上下文，生成日志。

根據以上的實現方式，無侵入式監控數據采集的整體調用順序如圖 10 所示：

圖 10：監控數據采集時序圖

在時序圖中，我們可以看到請求發送到前端應用時，將會調用 StartTrace 生成一個全局唯一的 TraceId，TraceId 使用了 IP + Timestamp + 順序數  + 進程號的方式保證唯一性。

其次通過對 StartRpc 的調用生成相應的 RpcId，它標識著一次請求的順序和嵌套關系，各個系統間傳遞，調用關系是同步、異步還是一對多調用。

通過使用 TraceId + RpcId 組合的方式完成整個調用鏈的異常數據標識和采集。

在監控數據采集過程中，也遇到過相關的難點，但是經過努力，也都一一解決，以下是我歸納的一些早前所遇到的問題和解決方法，可供大家參考。

愿景

未來，蘇寧將全面打造 AI 監控生態云平臺，對全生態監控體系實現無人值守的監控。

用戶可通過多種方式(語音、文本、動作)與機器人進行交互，機器人將給出用戶需要的分析數據，并能根據結果數據給出相應的解決方案。

以用戶為導向，形成用戶行為分析閉環，實現資源智能地分配與回收，讓監控改變世界。

作者：湯泳

簡介：蘇寧易購 IT 總部數據云公司監控研發中心總監，蘇寧一體化智能監控體系首席架構師。15 年從業背景，數學與計算機科學系畢業，師從中科院自然語言處理黃和燕導師，主導“云穆“立體式智能監控產品研發。這些產品服務于蘇寧控股集團八大產業 4000+ 系統、10W+ 服務，保障電商平臺日常和大促時段線上系統平穩運行。目前，致力于蘇寧 AIOps 能力建設。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】