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

一、背景

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

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

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

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

（二）缺乏一個(gè)快速有效的深度挖掘平臺(tái)

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

（三）缺乏面向一線和后端運(yùn)維人員的分析平臺(tái)

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

二、解決方案

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

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

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

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

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

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

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

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

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

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

APM識(shí)別業(yè)務(wù)請(qǐng)求中的TID，UID，通過關(guān)聯(lián)標(biāo)簽自動(dòng)關(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)動(dòng)機(jī)制，當(dāng)UEM分析出某些客戶端訪問某些具體的應(yīng)用慢時(shí)，將觸發(fā)與NPM/APM的聯(lián)動(dòng)，NPM收到APM反饋的客戶端和應(yīng)用的具體信息后，呈現(xiàn)出該客戶端和應(yīng)用在每個(gè)網(wǎng)絡(luò)監(jiān)控節(jié)點(diǎn)上的網(wǎng)絡(luò)性能信息。最后將網(wǎng)絡(luò)性能數(shù)據(jù)與應(yīng)用性能數(shù)據(jù)進(jìn)行關(guān)聯(lián)展示，實(shí)現(xiàn)快速、精準(zhǔn)的故障排查。

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

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

實(shí)現(xiàn)原理：

客戶端瀏覽器注入SDK。

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

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

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

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

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

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

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

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

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

UEM偏重用戶行為和相關(guān)業(yè)務(wù)的監(jiān)控，為深入了解云化架構(gòu)下的應(yīng)用各路徑節(jié)點(diǎn)的運(yùn)行情況，引入開源數(shù)據(jù)庫（Mongodb）+Spark流處理技術(shù)，對(duì)云服務(wù)器上網(wǎng)絡(luò)流量進(jìn)行實(shí)時(shí)動(dòng)態(tài)采集，根據(jù)代碼規(guī)范和業(yè)務(wù)規(guī)則對(duì)數(shù)據(jù)進(jìn)行過濾、排重，解碼，分析、計(jì)算和交易關(guān)聯(lián)，最終實(shí)現(xiàn)基于業(yè)務(wù)整體視圖級(jí)動(dòng)態(tài)監(jiān)控。基本原理和實(shí)現(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會(huì)話標(biāo)識(shí)將不同組件的原始數(shù)據(jù)包關(guān)聯(lián)成一個(gè)完整的會(huì)話流，并進(jìn)行協(xié)議解碼生成原始交易記錄；最后處理引擎根據(jù)已配置的業(yè)務(wù)規(guī)則對(duì)原始交易記錄進(jìn)行業(yè)務(wù)信息（如類型、渠道等關(guān)鍵字）提取、分析生成業(yè)務(wù)指標(biāo)記錄并將結(jié)果傳給負(fù)責(zé)web展現(xiàn)引擎后入庫。

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

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

4、指標(biāo)統(tǒng)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（六）U-B-A-N融合實(shí)踐

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

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

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

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

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

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

三、總結(jié)

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

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

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

追溯真實(shí)的一線用戶體驗(yàn)?；谟脩舨僮鞯臉I(yè)務(wù)模式匹配，實(shí)現(xiàn)真正的端到端實(shí)時(shí)定位分析，重點(diǎn)實(shí)現(xiàn)了對(duì)一線用戶真實(shí)感知的監(jiān)控。

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

本項(xiàng)目主要收益如下：

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

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

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

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

作者單位：中國移動(dòng)通信集團(tuán)山東有限公司