智能運維繫列專題簡介：智能運維（AIOps），根據Gartner的最新闡釋，意指整合大數據和機器學習能力，通過鬆耦合、可擴展方式去提取和分析數據量（volume）、種類（variety）和速度（velocity）這三個維度不斷增長的IT數據，進而爲IT運維管理產品提供支撐。在此，微衆銀行智能運維團隊根據一線工作的實踐經驗與心得體會，特別撰寫了《智能運維繫列》文章，本公衆號後期將陸續發佈，敬請持續關注。
點擊回顧：智能運維繫列（二）| 智能化監控領域探索
點擊回顧：智能運維繫列（三）| 淺析智能異常檢測——“慧識圖”核心算法
微衆銀行在事件識別越來越準的同時啓動了事件根因定位項目，以什麼爲定位的依據，以什麼爲推理的基礎一直是一個難點。通過對歷史案例的分析學習，我們發現交易的行爲路徑就像燈塔一樣指導我們找到問題的根本。全行的交易都通過消息總線傳遞，那麼消息總線中一定有我們需要的交易行爲路徑，可以繪製出所有交易的交易樹。
微衆銀行基於自研的消息總線WEMQ來提供金融級消息總線服務，所有的交易都會經過WEMQ進行通信，每筆交易都擁有唯一的交易流水號來識別。一筆交易從開始到結束，都會在WEMQ消息總線中留下調用信息，這裏稱之爲“原始消息日誌”。日誌中記錄了調用方信息、接收方信息、日誌記錄點（log_point）、發送時間、接收時間、交易流水號、具體的交易消息體等信息。正是基於此消息日誌和既定的規則，系統通過交易樹生成算法，從而形成了每筆交易的獨特交易樹。此交易樹可以應用於告警分析、根因分析等功能。
原始消息日誌處理流程圖
如圖1所示原始消息日誌會通過一些規則引擎預處理之後，得到消息對，每個消息對包含兩條message（request和response），代表一次調用；結合CMDB(配置管理數據庫)的數據對消息對進行處理，依據調用的響應方，生成多個tree node(一個響應方，一個節點)；將離散的tree node依據node的上游以及下游轉換成若干條tree chain；將若干條chain依據相同父鏈路等規則合併成樹，再做一些整理，如橫向合併、縱向合併就得到最後的交易樹，如圖2所示爲某交易的具體交易鏈路。
獲取需要處理的流水號對應的原始消息列表
首先我們需要獲取一筆交易所有的消息日誌，基於經驗大部分交易會在3分鐘之內完成，爲此我們在對消息日誌經過簡單的預處理後將其存儲在redis中，三分鐘後將具有相同流水號的數據進行聚合得到完整的交易流水日誌。一筆交易以交易流水號來辨識，包含多條原始消息；同一筆交易中存在唯一標識符（unique_id）來辨識是哪兩個子系統之間發生了調用。如A–>B，A向B發送請求request，B會回覆請求response。
將原始消息轉化爲消息對
兩個子系統之間的一次調用包含兩條消息（一次請求，一次回覆），在獲取到一筆交易的完整日誌後，首先需要對日誌按照調用進行聚合，對於同一個unique_id的原始消息會生成一個消息對，即兩個子系統之間的調用消息對。爲此我們制定了統一格式的消息對（req_message和rsp_message），需要從日誌中提取信息進行填充。
從WEMQ獲取到的是調用消息的日誌，不同版本的WEMQ API會上報格式不統一的日誌。對於新版WEMQ API一次調用存在2條日誌，對於舊版WEMQ API一次調用可能存在4條日誌。由於不同版本的日誌格式不同，會存在不同的log_point即記錄日誌點不同。根據WEMQ使用規範我們總結了原始消息的字段格式。
爲了得到消息對，首先將相同unique_id的消息按照log_point分組，將相同log_point的消息數據合併爲一條消息。然後初始化消息對(req_message, rsp_message)，根據歷史經驗總結出了不同log_point的日誌置信度，按照一定的規則引擎將多個log_point日誌中的信息填充到req_message和rsp_message中，得到最終的消息對。
消息對轉化爲樹節點
原始消息轉化爲消息對後，首先需要將消息對中的屬性進行預處理，如某些屬性缺失可以通過CMDB中的信息進行補充。另外在CMDB中還保存有完整的子系統與其提供的服務響應的對應關係，而在消息對的req_message中詳細記錄了調用哪個子系統的哪個服務，基於此對應關係，我們可以得到所有可能的下游節點。根據消息對中的rsp_message及一定的規則引擎，我們將消息對轉化爲了樹節點。依據調用的響應方，可能會生成多個tree node（一個響應方，一個節點）。
如果消息對中調用的服務在CMDB中找不到提供相應服務的子系統，則無法生成樹節點，被稱爲孤立消息對。
樹節點轉化爲鏈路
至此，我們已經將一筆交易中的原始消息轉化爲了多個樹節點，現在將其按照一定的規則轉化爲鏈路。首先要選取一個根節點，然後尋找下游節點依次拼接。在我們的交易流水號中記錄了根節點的子系統id，然後遍歷所有的節點，如果某節點的發送方屬性（如子系統、ip等）和根節點的接收方屬性相同，則將該節點拼接到根節點後面，形成一條鏈路。接着重複上述步驟遍歷剩餘節點，將符合上述條件的節點匹配到每條鏈路的葉子節點中。
我們就將離散的樹節點轉換爲了若干條鏈路，一個樹節點可能同時出現在多條鏈路中。若從流水號中沒有獲取到根節點子系統id，嘗試從已經按照時間排序的樹節點中獲取前三個節點的子系統id作爲根節點嘗試生成鏈路。如果能夠將所有節點都拼接到鏈路中則選擇該方案。如果有節點拼接不到鏈路中則選取剩餘孤立節點最少的那個樹節點作爲根節點。
合併鏈路生成交易樹
我們已經得到了若干條鏈路，距離交易樹生成還有最後一步。首先對每條鏈路進行預處理。如果同一條鏈路中上游節點的接收方屬性和發送方屬性相同，則表示自己調用自己，做合併處理即縱向合併（調用自循環）。接着對於不同的鏈路進行處理，如果不同的鏈路中存在上下游屬性完全一致的情況，意味着具有相同的父鏈路，做合併處理即橫向合併。
按照上述規則合併完成得到原始的交易樹，對其進行簡單整理，將同一層級的子節點按照時間升序排序得到最終的交易樹。
總結
上面我們詳細介紹瞭如何基於WEMQ中的原始消息日誌及CMDB中的信息生成交易樹，我們將原始的消息日誌和已經生成的交易樹結構進行存儲，展示在界面上便於行內運維及開發人員對於具體交易進行搜索，對於交易的整體流程有清晰的感受。另外基於交易樹，我們還獲取了包括子系統信息，告警信息，日誌信息等各維度內容展示在前端，方便查看交易的詳細狀態。
由於我行的業務量很大，每天有很多交易，這些交易樹中包含了很多有價值的信息。我們對於每筆交易利用具體的交易樹信息生成交易樹的唯一標識treekey，可以對全量交易進行歸類統計分析，得到全行各系統的運行狀況。另外我們還通過算法識別出交易歸屬的產品場景，可以得到整個產品場景的交易森林，對整個產品場景的框架有清晰的感知。交易森林的建立即是交易大數據，在此基礎上我們可以做很多的數據挖掘。異常根因定位就是其中的一個應用場景，下一篇將介紹如何使用交易樹進行異常根因定位的。期待下次與你分享。
作者介紹
微衆銀行智能運維繫統核心開發者王國峯