韓宇 李世沖 朱祥磊 何啟明 王新安 孔慶濤 李濤

一、背景

隨著云化演進，運營商CRM系統(tǒng)正在由面向數(shù)以千計的操作員轉(zhuǎn)變化為面向數(shù)以千萬計最終用戶的系統(tǒng)，系統(tǒng)規(guī)模也呈幾十倍增長，業(yè)務(wù)監(jiān)控體系逐步由“關(guān)注系統(tǒng)完好性”的集中式監(jiān)控演進為以“關(guān)注客戶體驗”為核心的分布式監(jiān)控體系。對監(jiān)控的自動化和智能化提出了更高的要求。

傳統(tǒng)業(yè)務(wù)監(jiān)控方法僅能從個別因素進行監(jiān)控（如僅針對具體業(yè)務(wù)、僅針對網(wǎng)絡(luò)、僅針對應(yīng)用等），無法從客戶體驗和業(yè)務(wù)全流程角度實現(xiàn)整體粒度和細粒度統(tǒng)籌監(jiān)控管理，主要表現(xiàn)在以下幾點：

（一）缺乏面向業(yè)務(wù)全流程的智能分析系統(tǒng)

業(yè)務(wù)由多個應(yīng)用組成，而每個應(yīng)用部署位置環(huán)境都不一樣，核查分析業(yè)務(wù)需要跨多臺主機。無法實現(xiàn)以業(yè)務(wù)為視角的立體式全景監(jiān)控分析。

（二）缺乏一個快速有效的深度挖掘平臺

各個應(yīng)用缺少業(yè)務(wù)明細日志分析，無法從地市、業(yè)務(wù)渠道、業(yè)務(wù)類型、 影響時間、成功率等各個更細的維度找出系統(tǒng)應(yīng)用和業(yè)務(wù)瓶頸，無法針對性地進行深度挖掘分析。

（三）缺乏面向一線和后端運維人員的分析平臺

日益復(fù)雜多樣的業(yè)務(wù)，運維人員每日游走在各主機中提取相關(guān)數(shù)據(jù)， 再進行匯聚分析，使得運維的工作日益繁重。故障發(fā)現(xiàn)也變得被動、故障定位過程復(fù)雜和耗時。

二、解決方案

（一）新的業(yè)務(wù)監(jiān)控方法論：U-B-A-N

核心思想：以業(yè)務(wù)為主線，涵蓋從用戶端到末端數(shù)據(jù)庫端的全鏈路監(jiān)控，實現(xiàn)業(yè)務(wù)從用戶發(fā)起到返回的全路徑跟蹤，實現(xiàn)從面到點的監(jiān)控。

主體內(nèi)容包含四部分，UEM（客戶體驗）、BPM（業(yè)務(wù)）、APM（應(yīng)用）、NPM（網(wǎng)絡(luò)）。通過4部分的獲取，可構(gòu)成一個完整的業(yè)務(wù)監(jiān)控全鏈路覆蓋，形成一體化業(yè)務(wù)保障體系，從而可以實現(xiàn)整體視圖、快速定位故障和預(yù)警故障。

UEM（U）即用戶體驗管理，負責從前端用戶的操作交互中獲取相關(guān)指標數(shù)據(jù)，需要進行交易解碼、關(guān)聯(lián)、追蹤分析等；

NPM（N）即網(wǎng)絡(luò)性能管理，負責對交易全流程網(wǎng)絡(luò)的監(jiān)控和分析，主要涉及鏈路質(zhì)量、流量、傳輸、時延等相關(guān)方面；

APM（A）：即應(yīng)用性能管理，對后端應(yīng)用自身的端到端調(diào)用鏈分析，涉及應(yīng)用性能、異常情況、負載情況等相關(guān)指標；

BPM（B）：業(yè)務(wù)性能管理，從業(yè)務(wù)的角度進行相關(guān)運行指標分析，如業(yè)務(wù)交易的解碼、關(guān)聯(lián)、追蹤分析等。

上述U-B-A-N分層監(jiān)控，又可以通過大數(shù)據(jù)技術(shù)實現(xiàn)統(tǒng)一智能關(guān)聯(lián)：

UEM端 WEB SDK自動在業(yè)務(wù)請求中插入關(guān)聯(lián)標簽如UID/TID，標識唯一用戶的唯一一次的業(yè)務(wù)請求。

NPM與BPM通過旁路數(shù)據(jù)包解碼識別TID/UID，將WEB端和數(shù)據(jù)中心、業(yè)務(wù)流與網(wǎng)絡(luò)流關(guān)聯(lián)起來。

APM識別業(yè)務(wù)請求中的TID，UID，通過關(guān)聯(lián)標簽自動關(guān)聯(lián)支撐業(yè)務(wù)的應(yīng)用服務(wù)器端，通過內(nèi)在的SPAN技術(shù)關(guān)聯(lián)應(yīng)用服務(wù)器調(diào)用的數(shù)據(jù)庫、第三方接口服務(wù)等。

UEM/NPM/BPM/APM之間采用聯(lián)動機制，當UEM分析出某些客戶端訪問某些具體的應(yīng)用慢時，將觸發(fā)與NPM/APM的聯(lián)動，NPM收到APM反饋的客戶端和應(yīng)用的具體信息后，呈現(xiàn)出該客戶端和應(yīng)用在每個網(wǎng)絡(luò)監(jiān)控節(jié)點上的網(wǎng)絡(luò)性能信息。最后將網(wǎng)絡(luò)性能數(shù)據(jù)與應(yīng)用性能數(shù)據(jù)進行關(guān)聯(lián)展示，實現(xiàn)快速、精準的故障排查。

（二）客戶體驗監(jiān)控UEM

主要用于監(jiān)控前端用戶真實使用體驗，用戶端通過SDK注入實現(xiàn)云化后的用戶體驗監(jiān)控相較其他方式，數(shù)據(jù)無丟失，度量更加真實可靠。

實現(xiàn)原理：

客戶端瀏覽器注入SDK。

捕獲用戶客戶端行為和對應(yīng)服務(wù)端請求。

記錄用戶操作的響應(yīng)時間（客戶端時間、網(wǎng)絡(luò)時間、服務(wù)器處理時間等） 。

定期從用戶瀏覽器發(fā)送文件給服務(wù)端 。

服務(wù)器單獨或分組分析展示業(yè)務(wù)情況。

以實際案例中基于用戶體驗技術(shù)查找網(wǎng)絡(luò)速度慢的終端為例，簡介如下：

原理方法：連網(wǎng)速度慢的一個特征是服務(wù)端在接收用戶上行請求的參數(shù)部分存在延遲（Inbound Time Delay），利用此特征，在服務(wù)器端安裝傳感器，截獲解析參數(shù)緩慢的請求，并進一步找到網(wǎng)絡(luò)速度慢的終端 。

監(jiān)控步驟：首先搜索超時請求在服務(wù)器端的代碼路徑，查詢到處理時間熱點，然后基于關(guān)鍵代碼創(chuàng)建測量，最后輸出超時請求記錄 。

實施效果：對全省17地市自助終端網(wǎng)絡(luò)響應(yīng)速度增加了監(jiān)控，在一個周期（7天）內(nèi)按照超時次數(shù)排名，輸出問題終端列表，反饋地市整改。

（三）業(yè)務(wù)性能監(jiān)控BPM

UEM偏重用戶行為和相關(guān)業(yè)務(wù)的監(jiān)控，為深入了解云化架構(gòu)下的應(yīng)用各路徑節(jié)點的運行情況，引入開源數(shù)據(jù)庫（Mongodb）+Spark流處理技術(shù)，對云服務(wù)器上網(wǎng)絡(luò)流量進行實時動態(tài)采集，根據(jù)代碼規(guī)范和業(yè)務(wù)規(guī)則對數(shù)據(jù)進行過濾、排重，解碼，分析、計算和交易關(guān)聯(lián)，最終實現(xiàn)基于業(yè)務(wù)整體視圖級動態(tài)監(jiān)控?；驹砗蛯崿F(xiàn)過程如下：

1、業(yè)務(wù)配置

從業(yè)務(wù)渠道維度出發(fā)，根據(jù)業(yè)務(wù)訪問關(guān)系，梳理出系統(tǒng)部署圖和業(yè)務(wù)關(guān)系視圖，包括系統(tǒng)內(nèi)部相互之間訪問關(guān)系、訪問端口，組件屬性，協(xié)議解碼等。

2、數(shù)據(jù)采集和流處理

流處理中心從TAP中心捕獲數(shù)據(jù)并轉(zhuǎn)換為原始數(shù)據(jù)包。其次解碼器根據(jù)TCP會話標識將不同組件的原始數(shù)據(jù)包關(guān)聯(lián)成一個完整的會話流，并進行協(xié)議解碼生成原始交易記錄；最后處理引擎根據(jù)已配置的業(yè)務(wù)規(guī)則對原始交易記錄進行業(yè)務(wù)信息（如類型、渠道等關(guān)鍵字）提取、分析生成業(yè)務(wù)指標記錄并將結(jié)果傳給負責web展現(xiàn)引擎后入庫。

3、動態(tài)監(jiān)控

負責指標展現(xiàn)引擎（exporter）獲取到數(shù)據(jù)后，將結(jié)果實時更新到前臺web相應(yīng)組件。

4、指標統(tǒng)計

告警模塊（alerter）輪詢數(shù)據(jù)庫中記錄根據(jù)業(yè)務(wù)配置基線和閥值生成趨勢報告和告警信息（如：業(yè)務(wù)量、成功率、響應(yīng)率、業(yè)務(wù)平均受理時長等）

舉一個實際案例：在8月31日上午10點左右，收到營業(yè)一區(qū)和營業(yè)三區(qū)的系統(tǒng)告警，具體定位過程如下：

打開監(jiān)控系統(tǒng)前臺，發(fā)現(xiàn)營業(yè)一區(qū)和營業(yè)三區(qū)的WEB服務(wù)器平均響應(yīng)時間（1000～2000ms）要遠大于平時（100多ms），而前端WEB服務(wù)器和后端交易中間件服務(wù)指標正常，初步判斷問題出現(xiàn)在WEB端。

點擊出問題WEB服務(wù)節(jié)點，進入業(yè)務(wù)量明細界面，可以看出10點左右業(yè)務(wù)量在降低，但響應(yīng)時長反而在增加。

點擊業(yè)務(wù)明細，查看當前所有業(yè)務(wù)的受理情況（業(yè)務(wù)量、地市、業(yè)務(wù)平均響應(yīng)時長、成功率等信息）。

根據(jù)業(yè)務(wù)排序，發(fā)現(xiàn)10點左右，有地市做批量業(yè)務(wù)，占用了大量了系統(tǒng)資源，導致營業(yè)一系統(tǒng)慢。緊急停止批量業(yè)務(wù)（挪到晚上進行）后，系統(tǒng)逐步恢復(fù)正常。

（四）應(yīng)用性能監(jiān)控APM

無論是UEM，還是BPM，都是粗粒度監(jiān)控，在很多情況下，如出現(xiàn)應(yīng)用問題還需要更加細粒度的診斷手段。為此，需要引入基于代碼級的業(yè)務(wù)監(jiān)控手段（APM），用于解決應(yīng)用云化后復(fù)雜環(huán)境下的問題定位診斷場景。

APM基于JVMTI可以追蹤和監(jiān)控任何一筆用戶請求在服務(wù)器端的代碼軌跡，通過對比堆棧上各層函數(shù)耗時，可以迅速找出執(zhí)行熱點，并定位到性能問題的根因。同時，對調(diào)用的函數(shù)啟用出入?yún)?shù)捕獲，可以詳細了解業(yè)務(wù)執(zhí)行時的快照，幫助定位業(yè)務(wù)層面的問題。

應(yīng)用實踐：在7月份營銷平臺中間件進程經(jīng)常僵死，需重啟才能恢復(fù)，嚴重影響客戶服務(wù)。

通過APM定位原因和解決過程如下：

從BPM端到端監(jiān)控查看，可獲取推薦營銷事件觸發(fā)業(yè)務(wù)存在大量線程等待；

從APM代碼級分析查看，事件服務(wù)執(zhí)行時存在對內(nèi)存服務(wù)的調(diào)用，而內(nèi)存服務(wù)的熱點出現(xiàn)在對ArrayList（動態(tài)數(shù)組）的掃描中；

根據(jù)上述查看，定位根因：對容量超大的動態(tài)數(shù)組進行遍歷導致了性能問題。

獲得解決思路：采用HashSet或更高效的集合對象替代動態(tài)數(shù)組。

優(yōu)化效果：優(yōu)化后，事件服務(wù)性能提升20倍。問題解決。

（五）網(wǎng)絡(luò)性能監(jiān)控NPM

網(wǎng)絡(luò)因素在業(yè)務(wù)環(huán)節(jié)中屬于重要的層面，因為處于底層且專業(yè)性強，出現(xiàn)的問題往往很難定位，通過對重要的網(wǎng)絡(luò)節(jié)點與鏈路進行全方位的監(jiān)控覆蓋，建立全網(wǎng)網(wǎng)絡(luò)質(zhì)量的可視化視圖，并支持業(yè)務(wù)數(shù)據(jù)包的分析，從而實現(xiàn)從面到點的細化監(jiān)控，同時可通過旁路數(shù)據(jù)包解碼識別TID/UID，和BPM、APM、UEM關(guān)聯(lián)分析。

（六）U-B-A-N融合實踐

通過以上介紹的U-B-A-N的部署實踐，借助標簽關(guān)聯(lián)與大數(shù)據(jù)分析技術(shù)實現(xiàn)U-B-A-N的圖形化關(guān)聯(lián)分析。

以暑假促銷性能瓶頸診斷為例進行介紹整體流程：

暑促開始之后，通過UEM前端監(jiān)控到號卡直開的下單響應(yīng)時間從平均4秒增大到平均9秒，嚴重影響用戶感知。

在B P M上發(fā)現(xiàn)號卡直開業(yè)務(wù)中兩個業(yè)務(wù)openCardCheck和orderToEcp響應(yīng)時間總和超過9秒，在NPM上查看關(guān)聯(lián)的網(wǎng)絡(luò)數(shù)據(jù)包，延遲正常，說明號卡直開問題不是網(wǎng)絡(luò)問題，是由于ECP應(yīng)用響應(yīng)過慢引起的。

查看APM服務(wù)器端，發(fā)現(xiàn)大量異常，尤其出現(xiàn)SQL異常，根據(jù)SQL定位具體業(yè)務(wù)后進行針對性優(yōu)化。

優(yōu)化后級，第二天號卡直開業(yè)務(wù)響應(yīng)時間顯著下降，問題解決。

三、總結(jié)

通過實施基于U-B-A-N的業(yè)務(wù)監(jiān)控系統(tǒng)，初步達到了如下目標：

面向云架構(gòu)的業(yè)務(wù)監(jiān)控系統(tǒng)。傳統(tǒng)方式基于傳統(tǒng)應(yīng)用架構(gòu)、集中式監(jiān)控，無法適應(yīng)虛擬化、云架構(gòu)的場景。本方案實現(xiàn)針對云架構(gòu)的環(huán)境，適應(yīng)大規(guī)模云化運維，以UEM（客戶體驗）-BPM（業(yè)務(wù)）-APM（應(yīng)用）-NPM（網(wǎng)絡(luò)）的方式，實現(xiàn)業(yè)務(wù)全鏈路的監(jiān)控覆蓋。

構(gòu)建全棧業(yè)務(wù)可視化監(jiān)控分析。全面展示整個系統(tǒng)全棧指標，實時展現(xiàn)數(shù)據(jù)流和業(yè)務(wù)流各項指標。

追溯真實的一線用戶體驗。基于用戶操作的業(yè)務(wù)模式匹配，實現(xiàn)真正的端到端實時定位分析，重點實現(xiàn)了對一線用戶真實感知的監(jiān)控。

海量數(shù)據(jù)的交易追蹤，快速故障定位。單筆業(yè)務(wù)交易追蹤的能力根據(jù)特定信息（如手機號、流水號、TID/UID等）來追蹤交易經(jīng)過的所有業(yè)務(wù)環(huán)節(jié)的性能和結(jié)果，快速精準定位故障原因。

本項目主要收益如下：

提升業(yè)務(wù)監(jiān)控效率、保障系統(tǒng)連續(xù)運營。

目前已部署在山東移動所有重點業(yè)務(wù)受理渠道，系統(tǒng)故障能夠?qū)崟r告警，并能將故障可視化，自動給出故障原因分析，大大降低故障處理時限。自系統(tǒng)上線以來，共及時發(fā)現(xiàn)系統(tǒng)性能問題近20例，因為及時發(fā)現(xiàn)處理未影響營業(yè)各系統(tǒng)連續(xù)性。

系統(tǒng)運營能力提升。

結(jié)合監(jiān)控數(shù)據(jù)分析，優(yōu)化業(yè)務(wù)處理邏輯和系統(tǒng)部署，提升了各業(yè)務(wù)成功率，降低交易時長，從而提高運營能力。

作者單位：中國移動通信集團山東有限公司