中國移動通信集團河北有限公司 潘霞

作為移動運營商的核心生產(chǎn)系統(tǒng)，故障管理系統(tǒng)在日常的運維保障中起著至關(guān)的作用。故障管理系統(tǒng)主要包含三類基礎(chǔ)數(shù)據(jù)：資源、性能和告警數(shù)據(jù)。隨著LTE的建設(shè)和無線WIFI普及的拉動，移動的網(wǎng)絡(luò)規(guī)模不斷擴大。其資源、性能和告警數(shù)據(jù)也隨之爆炸增長，這給故障管理系統(tǒng)告警數(shù)據(jù)的實時處理帶來了不小的壓力。本文從告警的處理流程入手，分析其中的性能瓶頸，并結(jié)合實際情況建立起告警數(shù)據(jù)的分布式處理機制。

告警處理過程中的性能瓶頸

故障管理系統(tǒng)每天要處理大量的告警數(shù)據(jù)，這些數(shù)據(jù)有以下特點：

1、數(shù)據(jù)量大：告警數(shù)據(jù)超400萬條/天（含設(shè)備和性能告警）；

2、數(shù)據(jù)變化非線性：存在瞬時峰值超過1000條/秒情況，超過平時處理量十倍以上；

3、數(shù)據(jù)實時性高：告警數(shù)據(jù)需要實時處理并及時呈現(xiàn)在頁面上，其中設(shè)備告警時延控制在秒級；

4、處理復(fù)雜度高：單條告警要經(jīng)資源填充、標準化處理、關(guān)聯(lián)分析、派單規(guī)則匹配、預(yù)處理規(guī)則匹配等多批次長流程操作；

5、數(shù)據(jù)的時序性：同一條告警內(nèi)部以及同一網(wǎng)元產(chǎn)生的新告警和清除告警都需要按照順序執(zhí)行相應(yīng)的操作。

以前，告警系統(tǒng)為了滿足數(shù)據(jù)處理的實時性、時序性和復(fù)雜度高的要求，采用了單線程的處理機制。即首先把告警消息緩存到一個消息隊列中，然后通過一個單獨的線程做后續(xù)的相關(guān)操作。由于告警數(shù)據(jù)巨大，常出現(xiàn)處理不及時導(dǎo)致入庫延時、派單延時、頁面呈現(xiàn)延時等一系列問題。

另外，這些實時處理模塊都是部署在實體機上，且單機部署單機運行。不僅擴展存在成本和升級困難情況，也存在程序故障或者服務(wù)器故障多方面的安全隱患。

總結(jié)起來，以前的告警處理機制存在并發(fā)數(shù)受限、處理延時較大、安全性低、不易擴展等問題。在數(shù)據(jù)量日益增長的趨勢下，已經(jīng)不能滿足故障管理系統(tǒng)的要求。

問題分析

我們以告警的處理流程為例來分析問題所在，如圖1所示：

1、從告警隊列里邊取出一條告警，通過和資源關(guān)聯(lián)把相關(guān)必要字段填充到告警對象中；

2、根據(jù)標準化規(guī)則對告警做標準化處理；

3、根據(jù)事先定義好的關(guān)聯(lián)規(guī)則對告警做關(guān)聯(lián)分析；

4、根據(jù)事先定義好的派單規(guī)則對告警做派單匹配，如果有匹配上的規(guī)則，則在對應(yīng)的時間做自動派單；

5、根據(jù)事先定義好的智能預(yù)處理規(guī)則對告警做匹配，如果有匹配上的規(guī)則，則把告警發(fā)給預(yù)處理模塊做智能預(yù)處理；

6、告警消息發(fā)送到各應(yīng)用模塊進行數(shù)據(jù)消費；

7、告警入庫。

由告警處理流程圖可以看出：

每條告警中的處理步驟需要按順序執(zhí)行；

根據(jù)告警數(shù)據(jù)的特點，同一網(wǎng)元產(chǎn)生的新告警和清除告警處理順序不能錯亂；

由于告警數(shù)據(jù)量大，告警的入庫環(huán)節(jié)采用定時批量入庫的方式；

關(guān)鍵問題：

告警的處理環(huán)節(jié)多，過程復(fù)雜，耗時長是影響告警數(shù)據(jù)準確可靠的重要問題；

告警的數(shù)據(jù)量大，且執(zhí)行順序要求較高，是影響告警處理效率的主要原因；

上述關(guān)鍵問題的解決點在于在每條告警被完整有序處理的前提下盡可能地

提高并發(fā)處理的能力。

技術(shù)支撐

該方案的主要目標是為了解決兩個關(guān)鍵問題：即每條告警被完整有序的處理，以及增加并發(fā)處理能力。

告警實時數(shù)據(jù)量大是告警處理效率低下的主要原因，因此方案中必須解決對大數(shù)據(jù)的高效處理能力，否則處理過程再優(yōu)美，邏輯再嚴謹也無濟于事。傳統(tǒng)的解決方案是在單一服務(wù)器上通過盡可能地增加硬件配置（如cpu、內(nèi)存等）來提高實時數(shù)據(jù)的處理能力。但事實上現(xiàn)在先進的系統(tǒng)不僅要求處理能力出眾，還必須具有可擴展、高容錯、高并發(fā)等特點。顯然單機運行方案已經(jīng)完全不能適應(yīng)系統(tǒng)的技術(shù)要求，尤其是移動運營商的核心生產(chǎn)系統(tǒng)。

圖1 告警處理流程

基于以上原因，本方案致力于尋求一種可以對實時大量數(shù)據(jù)進行快速處理，并能夠保證數(shù)據(jù)處理順序和完整可靠的解決手段。伴隨著近幾年互聯(lián)網(wǎng)的高速發(fā)展，應(yīng)運而生的是海量的信息數(shù)據(jù)，并且已經(jīng)出現(xiàn)一些實時處理海量數(shù)據(jù)的可靠方法。這次我們選用的是較為成熟的Storm技術(shù)。一個實時的、分布式的、具備高容錯的計算系統(tǒng)，來作為告警數(shù)據(jù)實時處理的解決方案。

Storm主要特點：

1、可以處理大批量的數(shù)據(jù)；

2、在保證高可靠性（所有的信息都會被處理）的前提下讓處理進行的更加實時；

3、易于擴展，通過新增設(shè)備來提高系統(tǒng)處理能力；

4、具備容錯機制，如果任務(wù)執(zhí)行失敗，Storm會重新分配再次執(zhí)行。

解決方案

Storm處理邏輯，業(yè)界也稱為流式處理。圖2是基于Storm架構(gòu)的告警實時數(shù)據(jù)處理流程圖：

圖2 基于Storm的告警處理流程

在此架構(gòu)下，所有的告警處理節(jié)點任務(wù)可以被平均分配在不同服務(wù)器上，并受Supervisor進程的調(diào)度和管理。系統(tǒng)會根據(jù)事先配置好的策略來分配告警數(shù)據(jù)的流向，最終穩(wěn)定高效完成所有的處理節(jié)點。

方案特點：

對于同一個處理節(jié)點，會部署在多臺機器上，每臺機器都可以啟動多個線程來同時處理該節(jié)點的任務(wù)；

一條告警在經(jīng)過第n個處理節(jié)點后，可以設(shè)置不同的分發(fā)策略分發(fā)給第n+1個節(jié)點；

對于無序的兩條告警（比如兩個網(wǎng)元產(chǎn)生的不同新告警），我們可以采用混排分組策略，此種策略Storm會隨機分發(fā)給能夠處理第n+1個節(jié)點的多個任務(wù)中的其中一個，并保證每個工作節(jié)點可以分配到較為平均的任務(wù)數(shù)；

對于有序的告警（比如同一個網(wǎng)元和新告警和清除告警，只能先處理新告警，再處理清除告警），我們可以設(shè)置按照告警的某個字段分組，比如使用告警標識來分組，那么Storm就會對告警標識相同的告警分配給同一個任務(wù)來處理，從而保證了執(zhí)行的順序。

對于同一告警處理節(jié)點的多個任務(wù)，如果有其中一個或多個任務(wù)發(fā)生了故障或者異常，Storm會記錄它的執(zhí)行狀態(tài)，使未處理完成的告警重新分配給其它任務(wù)來處理，并不再發(fā)送告警數(shù)據(jù)給這些故障的任務(wù)直至故障恢復(fù)；

分布式的部署和執(zhí)行，保證了系統(tǒng)的可擴展性。隨著移動網(wǎng)絡(luò)規(guī)模的不斷擴大，告警數(shù)據(jù)也必然會大量增加，我們可以很容易地通過新增設(shè)備的方式來提高系統(tǒng)的處理能力；

系統(tǒng)中的一個或多個工作節(jié)點如果發(fā)生故障，主節(jié)點將不會再發(fā)送告警數(shù)據(jù)給此工作節(jié)點，其它工作節(jié)點可以繼續(xù)工作并分擔(dān)故障工作節(jié)點的任務(wù)，待故障工作節(jié)點恢復(fù)后再接收告警數(shù)據(jù)。

硬件部署：

使用兩臺服務(wù)器（配置均為：CPU，AMD6100 4*16；內(nèi)存，96G，硬盤，2*600G）采用分布式的方式來部署故障管理系統(tǒng)，這樣系統(tǒng)將會有一個主節(jié)點（部署在服務(wù)器A上）和兩個工作節(jié)點（一個部署在服務(wù)器A上，一個部署在服務(wù)器B上）組成，它們之間通過zookeeper進行協(xié)調(diào)通信。主節(jié)點的后臺程序Nimbus用于響應(yīng)分布在集群中的節(jié)點，分配任務(wù)和監(jiān)測故障；工作節(jié)點的后臺程序Supervisor用于收聽工作指派并基于要求運行工作進程。

隨著處理數(shù)據(jù)量的增加，依賴Storm架構(gòu)的橫向擴展能力，系統(tǒng)可靈活增加工作節(jié)點。實現(xiàn)當(dāng)前大數(shù)據(jù)下的靈活橫向擴展。

總結(jié)

本方案從告警數(shù)據(jù)的處理過程入手，分析了告警數(shù)據(jù)處理過程中的性能瓶頸以及產(chǎn)生的原因，并采用當(dāng)前相對成熟的Storm實時計算系統(tǒng)，有力提升了故障管理系統(tǒng)中實時數(shù)據(jù)的處理能力。

目前，基于Storm架構(gòu)的故障管理流式處理系統(tǒng)已經(jīng)投入使用。極大提升了運營商對實時告警的處理和監(jiān)控能力，使得全專業(yè)故障管理成為可能。并且實現(xiàn)了系統(tǒng)自身負載均衡和自身監(jiān)控的能力，減輕了使用人員的勞動強度，降低了系統(tǒng)故障幾率。系統(tǒng)使用一年以來，創(chuàng)造了良好的經(jīng)濟效益和社會效益。

本方案中，運營商可以結(jié)合自身的網(wǎng)絡(luò)狀況和硬件情況，利于方案中的技術(shù)特點來優(yōu)化符合自身情況的實時數(shù)據(jù)處理系統(tǒng)。