甘 雯 ，文 鋒 ，宮大鵬 ，徐 鉭 ，黃甫光 ，張 健 ，蘇 雷

（1.中國移動通信集團廣西有限公司 南寧 530022；2.億陽信通股份有限公司 南寧 530022）

1 引言

綜合告警系統(tǒng)是CMOSS2.0規(guī)劃的綜合網(wǎng)管系統(tǒng)，系統(tǒng)主要從OMC（operation and maintenance center，操作維護中心）等廠商網(wǎng)管系統(tǒng)獲取資源、告警、性能數(shù)據(jù)，包括從資源管理系統(tǒng)獲取資源數(shù)據(jù)、從各專業(yè)網(wǎng)管獲取告警和性能數(shù)據(jù)、從電子運維系統(tǒng)獲取工單數(shù)據(jù)等，然后通過列表、圖表、拓撲、GIS（geographic information system）等方式進行數(shù)據(jù)的匯總呈現(xiàn)，幫助監(jiān)控人員了解全網(wǎng)的運行狀態(tài)。

在通信網(wǎng)絡運行過程中，告警是網(wǎng)絡管理員最為關注的。當系統(tǒng)出現(xiàn)影響正常業(yè)務的故障時，這些重要的故障信息會以告警的方式在第一時間通知管理人員并應該立即得到解決，否則，可能會導致提供服務失敗。為了方便運維人員處理告警和迅速定位告警源，綜合告警系統(tǒng)采取了各種方式處理這些告警信息，比如告警展現(xiàn)、長時間未處理的告警提示、告警轉(zhuǎn)發(fā)、告警過濾、告警相關性分析等。

在一種極端的情況下，眾多網(wǎng)元（BTS（base transceiver station，基站收發(fā)信臺）、RNC（radio network controller，無線網(wǎng)絡控制器）、Node B等）由于不特定原因，同時并且長時間地向網(wǎng)管系統(tǒng)上報大量的告警，導致告警風暴的發(fā)生。如果告警系統(tǒng)沒有及時處理，容易造成海量告警的堆積，導致網(wǎng)管系統(tǒng)癱瘓，失去管理和監(jiān)控網(wǎng)絡的能力，更不能有效遏制網(wǎng)絡故障的進一步擴大。所以告警風暴的危害是巨大的，一方面應該盡量避免告警風暴的產(chǎn)生；另一方面，當告警風暴到來時，系統(tǒng)應有能力及時應對，將告警風暴的危害降到最低。

國外的研發(fā)機構(gòu)一般通過研究告警關聯(lián)性和告警挖掘技術解決此項難題，例如，惠普公司的Event Correlation Services，是基于規(guī)則的方法研究出的告警相關性分析系統(tǒng)；IBM采用基于事例的告警相關性分析方法，研制了NetFACT系統(tǒng)，利用告警相關性的研究對告警發(fā)生進行業(yè)務關聯(lián)，達到突出主用告警、抑制無用告警的目的，從而大大減少告警量。

近年來，國內(nèi)進行應對告警風暴研究的主要以設備廠商為主，例如中興通訊、華為技術、大唐電信等，都開始著力研制開發(fā)智能高效的移動通信網(wǎng)絡管理系統(tǒng)，包括告警相關性分析系統(tǒng)等。通過將一些研究成果融合到OMC、傳輸EMS（element management system，網(wǎng)元管理系統(tǒng)）等網(wǎng)管系統(tǒng)中，實現(xiàn)部分告警風暴抑制。

本文旨在探討對于架構(gòu)在設備廠商網(wǎng)管之上的綜合網(wǎng)管系統(tǒng)，如何通過升級現(xiàn)有架構(gòu)來應對告警風暴的發(fā)生，尋找合理的抑制告警風暴手段。

2 業(yè)務的高速發(fā)展和告警風暴的產(chǎn)生

所謂告警風暴往往被定義為在短時間內(nèi)，產(chǎn)生了大量的告警事件，在這些事件中，有的互相存在一定關聯(lián)，是由于某種共用因素導致的。這樣大量的告警在短時間內(nèi)擠壓告警上報通道，導致通道的堵塞甚至上層監(jiān)控業(yè)務的崩潰。近年來由于告警風暴導致的數(shù)據(jù)庫鎖死、隊列溢出、告警監(jiān)控服務掛死等現(xiàn)象時有發(fā)生，嚴重影響了運營商運維管理人員的日常監(jiān)控作業(yè)。

隨著網(wǎng)絡規(guī)模的不斷擴大、新類型網(wǎng)元接入以及跨專業(yè)監(jiān)控管理的現(xiàn)實需求，網(wǎng)管系統(tǒng)的數(shù)據(jù)接入量在不斷增加，但任何一個系統(tǒng)的運行均有其極限值，當數(shù)據(jù)處理效率不能滿足系統(tǒng)正常運行要求時，系統(tǒng)的可用性就會隨之下降，對于告警監(jiān)控這類實時消息系統(tǒng)表現(xiàn)得就更為明顯。當在一段時間內(nèi)的數(shù)據(jù)突增，超出系統(tǒng)處理能力時，會導致數(shù)據(jù)處理延時或者數(shù)據(jù)丟失，從而引發(fā)監(jiān)控系統(tǒng)的不可用。

如圖1所示，在具體的生產(chǎn)實踐中，工程割接、自然災害、OMC重啟、傳輸鏈路異常中斷等引起的告警風暴是數(shù)據(jù)風暴的典型場景。通常反應為：在超出現(xiàn)有告警監(jiān)控系統(tǒng)數(shù)據(jù)處理能力的情況下，監(jiān)控系統(tǒng)無法及時準確地將某個網(wǎng)元或者相關網(wǎng)元的告警解析呈現(xiàn)，從而無法起到監(jiān)控作用。

為了適應網(wǎng)絡規(guī)模和業(yè)務持續(xù)高速增長給網(wǎng)絡運維工作帶來的巨大壓力和挑戰(zhàn)，有力支撐公司未來發(fā)展，中國移動通信集團公司于2013年率先提出了“集中化”的網(wǎng)絡運維體制改革思路，經(jīng)過不斷建設和深化，已經(jīng)形成了全網(wǎng)跨專業(yè)的“集中監(jiān)控、集中維護、集中管理”格局。集中監(jiān)控的工作內(nèi)容之一是告警的集中監(jiān)控。隨著集中監(jiān)控規(guī)模的不斷發(fā)展，告警監(jiān)控工作面臨著前所未有的挑戰(zhàn)：由于集中化監(jiān)控的設備數(shù)量逐年快速增長，集中監(jiān)控對故障的處理質(zhì)量提出了更高的要求，特別是當告警風暴發(fā)生時，系統(tǒng)崩潰導致值班人員無法正常開展監(jiān)控工作，進而影響通信保障搶修。為此，迫切需要提高告警的準確性、有效性，并通過升級基礎架構(gòu)提高告警處理的效率，應對極端情況下的告警風暴發(fā)生。

圖1 告警數(shù)據(jù)風暴出現(xiàn)的主要場景分析

3 綜合告警的網(wǎng)管技術架構(gòu)升級

3.1 應對告警風暴的性能提升思路

在實際優(yōu)化過程中，影響系統(tǒng)運行效率的原因是多方面的。網(wǎng)絡傳輸效率、硬件性能、MQ配置、應用軟件部署方式、采集軟件配置、數(shù)據(jù)庫效率、產(chǎn)品設計都會對系統(tǒng)性能造成影響。

河南省戰(zhàn)略性新興產(chǎn)業(yè)專利特別是發(fā)明專利的數(shù)量與質(zhì)量，體現(xiàn)了河南省自主科技創(chuàng)新實力的強弱。通過對河南省戰(zhàn)略性新興產(chǎn)業(yè)專利競爭情報、專利數(shù)量、專利被引次數(shù)、專利成長率、專利實施率、產(chǎn)業(yè)標準化等指標經(jīng)濟與技術方面的統(tǒng)計與分析，可以為河南省戰(zhàn)略性新興產(chǎn)業(yè)自主創(chuàng)新能力的提升提供決策參考。河南省戰(zhàn)略性新興產(chǎn)業(yè)專利能力的提升與競爭優(yōu)勢的培育，需要政府與相關企業(yè)正確制定專利戰(zhàn)略，對專利進行前瞻性布局，提升核心專利技術的自主化水平，實施專利運營能力提升工程，以及構(gòu)建知識產(chǎn)權(quán)驅(qū)動型的創(chuàng)新發(fā)展人才體系等，以推動河南省戰(zhàn)略性新興產(chǎn)業(yè)的高質(zhì)量發(fā)展。

如圖2所示，告警風暴主要通過OMC產(chǎn)生，一旦產(chǎn)生，需要監(jiān)控人員引起重視。告警風暴處理包含風暴抑制和風暴后處理兩部分內(nèi)容：風暴抑制是系統(tǒng)判斷告警風暴產(chǎn)生后，將告警經(jīng)過特殊通道直接傳遞到消息平臺，并將風暴告警保存到文件中，或者停止對某個網(wǎng)元某個告警標題的采集；風暴后處理是將風暴期間的告警入庫，以便于統(tǒng)計分析，并且將風暴期間漏掉的告警通過正常流程發(fā)送上去。告警風暴產(chǎn)生或已經(jīng)停止時，系統(tǒng)產(chǎn)生預警消息，包括活動告警、清除告警。

從告警來源和架構(gòu)上分析，為有效應對告警風暴，考慮從硬件、軟件、中間件等方面入手進行針對性的調(diào)整。同時通過配置合理的日常維護管理制度，可大大減少告警風暴導致的業(yè)務中斷情況發(fā)生的幾率。

3.2 網(wǎng)絡及系統(tǒng)硬件調(diào)整手段

2014年以前，中國移動綜合告警系統(tǒng)主要實現(xiàn)了全專業(yè)告警接入、告警標準化、告警關聯(lián)、集客業(yè)務監(jiān)控、性能場景監(jiān)控等功能模塊。以廣西移動綜合告警項目為例，在優(yōu)化前，網(wǎng)管硬件平臺的網(wǎng)絡拓撲如圖3所示，系統(tǒng)部署在網(wǎng)管硬件平臺的2臺M9000服務器上，存儲使用網(wǎng)管硬件平臺的DX8700磁盤陣列。

隨著集中故障管理業(yè)務上線，經(jīng)過對告警業(yè)務的處理量、并發(fā)事務數(shù)、峰值進行測算，得到硬件TPC-C吞吐率（TPC-C使用3種性能和價格度量，其中性能由TPC-C吞吐率衡量，單位是tpmC，其含義為每分鐘內(nèi)系統(tǒng)處理的新訂單個數(shù)）的需求，進而推算出擴容方案，具體如下。

·系統(tǒng)數(shù)據(jù)庫服務器需要約149萬tpmC處理能力，當數(shù)據(jù)庫與MQ服務器同時部署在一臺服務器的時候，建議把綜合告警數(shù)據(jù)庫單獨拆分出來，利用已有M9000-2分區(qū)的計算能力，擴容4顆4核CPU，以滿足需求。

·采集服務器需要約127萬tpmC處理能力，將應用服務器的M9000分區(qū)的計算能力由6顆4核CPU內(nèi)存擴容至8顆4核CPU，擴容后可滿足需求。

·消息服務器需要約128萬tpmC處理能力。將目前應用服務器的M9000分區(qū)由6顆4核CPU擴容至8顆4核CPU，擴容后分區(qū)能滿足需求。

·拓撲服務器的能力需求為34.86萬tpmC，從其他機房的x86資源池劃分1臺總能力大于35萬tpmC的虛擬機以滿足需求。另外，為了保證必要的數(shù)據(jù)緩存機制，還增加了2 TB的存儲空間。

最終調(diào)整結(jié)束后，硬件網(wǎng)絡拓撲如圖4所示。

此外，對于上層應用服務器也需要做負載均衡。根據(jù)廣西14個地市的網(wǎng)絡及業(yè)務規(guī)模，將其分成大、中、小3類地市，制定了動態(tài)分配應用服務器的負載均衡策略。例如，當沿海城市發(fā)生臺風等自然災害，告警突增時，策略器就會自動分配登錄服務在當前空閑的機器上，保證性能使用的最大化。

通過硬件調(diào)整，可處理200萬條/天的告警并發(fā)負載量，參照歷史最嚴重的告警風暴發(fā)生，評估得出該硬件架構(gòu)能力可并發(fā)處理90%的告警。

圖2 告警風暴實例

圖3 綜合告警系統(tǒng)部署調(diào)整前拓撲

圖4 綜合告警系統(tǒng)部署調(diào)整后拓撲

3.3 軟件結(jié)構(gòu)升級手段

除了對硬件進行改造外，還通過對現(xiàn)有告警消息處理機制進行優(yōu)化來應對告警風暴。如圖5所示，告警在設備北向采集后會經(jīng)過清洗階段、標準化階段、分發(fā)入庫階段和上層展現(xiàn)階段，每個階段都可能會成為告警上報的性能瓶頸。特別是在大量告警隊列堆積時，有針對性地調(diào)整腳本的處理效率，可大大提升告警處理效率。

優(yōu)化手段可以從以下幾個方面考慮。

（1）智能并發(fā)告警采集

針對采集通道進行并行處理，設計軟負載均衡隊列管理語法，根據(jù)告警流量智能控制并行處理單元數(shù)，假設當A通道告警是B通道的兩倍時，會在給A通道多分配50%的處理進程，按照該算法，通過調(diào)整可提升單通道采集能力達到60條/s。

圖5 采集解析模塊優(yōu)化架構(gòu)

（2）基于高速緩存的告警處理系統(tǒng)

由于一般在告警標準化過程中，需要反復讀取告警進行標準化字段的翻譯。針對這種特點，可以利用高速緩存技術，如圖6所示，將待處理告警所需要的信息存儲在內(nèi)存中，加快了CPU的處理效率，迅速提升告警標準化、工程預約等標準化處理能力，提升整體處理能力達到 400條/s。

圖6 告警緩存建立示意

（3）基于高效規(guī)則處理和并發(fā)的告警訂閱分發(fā)系統(tǒng)

通過建立高效規(guī)則處理實現(xiàn)告警過濾器能力，識別多種閃現(xiàn)告警和關聯(lián)告警并予以合并或拋棄，并結(jié)合多并發(fā)分發(fā)處理，在并發(fā)多個過濾器（50個）情況下，提升分發(fā)效率，可以實現(xiàn)400條/s的處理速度。

基于流計算的告警關聯(lián)系統(tǒng)摒棄使用數(shù)據(jù)庫計算的方式，改為在接收告警流數(shù)據(jù)時就開始對其進行分析，通過實時的對象流計算，可快速處理告警之間的關聯(lián)關系，提升單規(guī)則處理能力，實驗表明可提升到200條/s。

（4）基于智能調(diào)度的告警派單處理能力提升

針對上層應用，告警的落地除了展現(xiàn)，更重要的是派單，提升EOMS派單系統(tǒng)自身處理效率可在業(yè)務上解決告警風暴的問題。針對EOMS單通道處理能力不夠的情況，通過建立智能的調(diào)度機制，動態(tài)并發(fā)調(diào)用，大幅提升派單能力，派單系統(tǒng)自身處理能力達到150條/s。

（5）數(shù)據(jù)庫調(diào)優(yōu)

通過對數(shù)據(jù)庫Oracle/Informix進行分片機制、增加索引，并對大量歷史數(shù)據(jù)進行拆分，也可以使得告警實時查詢速率提升。廣西移動采集模塊優(yōu)化測試結(jié)果見表1，以廣西移動實際項目測試結(jié)果為例，經(jīng)過優(yōu)化，可獲得顯著的提升效果。

表1 廣西移動采集模塊優(yōu)化測試結(jié)果

3.4 中間件參數(shù)配置手段

如圖7所示，消息隊列（MQ）是一種應用程序?qū)贸绦虻耐ㄐ欧椒?。應用程序通過“寫”和“檢索”出入列隊的針對應用程序的數(shù)據(jù)（消息）來通信，而無需專用連接器來鏈接它們。消息傳遞指的是程序之間通過在消息中發(fā)送數(shù)據(jù)進行通信，而不是通過直接調(diào)用彼此來通信，直接調(diào)用通常是用于諸如遠程過程調(diào)用的技術。排隊指的是應用程序通過隊列來通信。隊列的使用除去了接收和發(fā)送應用程序同時執(zhí)行的要求。

圖7 告警中間件MQ流程

IBM WebSphere MQ是綜合告警平臺使用的隊列中間件，對該中間件的參數(shù)配置進行優(yōu)化，可以起到優(yōu)化隊列長度，提高告警處理效率的效果。

對MQ進行了優(yōu)化調(diào)校，主要從服務器參數(shù)、MQ參數(shù)、MQ日志配置、隊列參數(shù)、緩沖區(qū)參數(shù)、程序API調(diào)用等多個方面，增強了服務器處理性能，提高了MQ服務的處理速度，減少了核心程序?qū)Q的壓力。具體為以下幾個方面的調(diào)優(yōu)。

·調(diào)整/etc/system系統(tǒng)參數(shù)，優(yōu)化MQ服務的數(shù)據(jù)處理性能。

·優(yōu)化MQ的斷網(wǎng)續(xù)傳參數(shù)，在Sun平臺下調(diào)整為：/usr/sbin/ndd-set/dev/tcptcp_keepalive_interval 15000。

· 優(yōu)化MQ的日志配置，修改/var/mqm/qmgrs/隊列管理器名稱為/qm.ini，調(diào)整日志文件的個數(shù)、每個日志文件的大小、日志緩沖區(qū)大小。

· 修改偵聽的啟動方式，采用runmqlsr方式提高通道相關的性能。

·設置偵聽程序采用trusted方式運行，降低CPU和內(nèi)存消耗。

· 增加通道的PipeLineLength屬性，設置MCA參數(shù)采用多個線程的方式傳輸消息，從而提高通道性能。

· 修改/var/mqm/qmgrs/隊列管理器名稱/qm.ini的TCP選項KeepAlive=Yes，使操作系統(tǒng)的TCP/IP參數(shù)設置對WebSphere MQ生效。

·修改核心程序?qū)Q的操作方式：MQCONN和MQDISC是最耗CPU的兩個函數(shù)，減少MQOPEN和MQCLOSE函數(shù)的調(diào)用，使用MQCONNX函數(shù)建立與隊列管理器的連接，使應用程序和本地隊列管理器代理組成同一個進程，從而提高性能。

以JFMHandler處理能力為例，經(jīng)過測試，效果如圖8所示。

優(yōu)化后，JFM處理消息的性能大約是544條/s，相比優(yōu)化前的400條/s處理能力提升了36%。

圖8 測試效果

3.5 服務異常檢測手段

為保證在告警風暴出現(xiàn)時，系統(tǒng)有能力對告警管理人員進行支撐，需要對告警系統(tǒng)新增服務負荷監(jiān)控模塊，對綜合告警客戶端發(fā)起連接到服務端請求的過濾器服務進行監(jiān)控，包括連接狀態(tài)、連接所占資源信息，方便監(jiān)控人員及時定位服務異常情況。一旦發(fā)現(xiàn)服務內(nèi)存溢出系統(tǒng)無法自行恢復時，可在最短時間內(nèi)通過手工進行恢復，保證業(yè)務連續(xù)性。

4 升級改造后取得的成效

在2013年，廣西移動發(fā)生過類似臺風災害場景產(chǎn)生180萬條/天的告警量，平均處理能力只有12.66條/s。在經(jīng)過了硬件擴容、軟件結(jié)構(gòu)優(yōu)化等調(diào)優(yōu)工作，并進行測試和部署調(diào)整后，經(jīng)過6個月的現(xiàn)網(wǎng)環(huán)境觀察，告警風暴處理能力有明顯提升。2014年7月，臺風威馬遜襲擊中國東南沿海，廣西受災。每天全網(wǎng)產(chǎn)生280萬條告警，形成特大告警風暴。平均每小時產(chǎn)生12萬條告警，峰值告警為15萬條，遠遠超過了系統(tǒng)的負載能力。經(jīng)過事后日志分析，告警風暴最嚴重的7月19日，平均處理能力可達到120.4條/s，入庫60.3條/s。峰值擠壓時可在1 h內(nèi)處理完畢。處理效率提高將近10倍，大大緩解了告警數(shù)據(jù)量的壓力。告警處理提升速度對照如圖9所示。

圖9 告警處理提升速度對照

告警風暴優(yōu)化后，處理速度比優(yōu)化前翻一番，細化了綜合監(jiān)控的支撐粒度，解決了遇到重大故障不可用的問題，實現(xiàn)了由面向網(wǎng)絡到面向客戶、由被動運維向主動運維的轉(zhuǎn)變。以業(yè)務主體為核心，實現(xiàn)故障的集中監(jiān)控、集中管理、工單直派一線，提高故障定位速度、分析和處理的效率，最終達到提升網(wǎng)絡運維質(zhì)量的目的。

5 結(jié)束語

隨著移動通信4G網(wǎng)絡的建設以及集中化運維體制改革的深入推進，一個能有效管理網(wǎng)絡的運行支撐系統(tǒng)就成為必不可少的工具，成為影響運營質(zhì)量的重要因素之一。通過升級綜合告警系統(tǒng)的軟硬件架構(gòu)，使之具備應對告警風暴的能力，能夠使得綜合告警平臺為網(wǎng)絡運維創(chuàng)造更多價值。

在研究過程中，參考了部分省級運營商的先進經(jīng)驗，結(jié)合自身“4+1”網(wǎng)管建設推進部署，每年都對系統(tǒng)進行深入研究，從業(yè)務（告警關聯(lián)）到技術（技術架構(gòu)）進行深度優(yōu)化，持續(xù)改進提升，以應對不斷變換的網(wǎng)絡環(huán)境，發(fā)揮網(wǎng)管系統(tǒng)的最大價值。

1 ITU-TRecM3200.TMNManagementServicesand Communications Managed Areas:Overview,2001

2 鄭慶國，呂衛(wèi)峰.通信網(wǎng)絡中的告警相關性研究.計算機工程與應用，2002(2)：11～15

Zeng Q G,Lv W F.Study on alarm correlation in communication network.Computer Engineering and Applications,2002(2)：11～15

3 石永革，梅玉潔，石峰.通信網(wǎng)網(wǎng)管告警過濾機制的研究與應用.計算機工程與設計,2008,29(9):2169～2171

Shi Y G,Mei Y J,Shi F.Research and application of communication network management alarm filtering mechanism.Computer Engineering and Design,2008,29(9):2169～2171

4 klemettinen M,Mannila H,Toivonen H.Rule discovery in telecommunication alarm data.Journal of Network and Systems Management,1999(4):395～423

5 潘沛.電信網(wǎng)絡綜合告警系統(tǒng)需求分析與設計.大眾科技,2009(5)

Pan P.Analysis and design of telecom network integrated alarm system requirements.Public Science and Technology,2009(5)

6 聞海舟.淺談電信網(wǎng)絡綜合告警系統(tǒng)建設方案.廣西通信技術,2011(2)

Wen H Z.The construction scheme of telecom network integrated alarm system.Guangxi Communication Technology,2011(2)

7 馮婧篧，李興明.基于加權(quán)關聯(lián)模式的通信網(wǎng)告警相關性分析.電信科學,2007,23(11)

Feng J Y,Li X M.Telecommunication alarm correlation analysis model based on weighted association.Telecommunications Science,2007,23(11)

8 李寶山，王蘇東.告警管理系統(tǒng)中的告警同步模塊的設計.通信技術,2013(4)

Li B S,Wang S D.Design of alarm synchronization module in the alarm management system.Communications Technology,2013(4)

9 Kettschau H J,Bruck S,Schefezik P L.An expert system for intelligent fault management and alarm correlation.Proceedings of Network Operation and Management Symposium (NOMS),Florence,Italy,April 2002