故障管理告警數(shù)據(jù)分布式處理

中國移動(dòng)通信集團(tuán)河北有限公司 潘霞

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

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

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

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

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

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

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

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

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

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

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

問題分析

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

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

2、根據(jù)標(biāo)準(zhǔn)化規(guī)則對(duì)告警做標(biāo)準(zhǔn)化處理；

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

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

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

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

7、告警入庫。

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

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

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

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

關(guān)鍵問題：

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

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

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

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

技術(shù)支撐

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

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

圖1 告警處理流程

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

Storm主要特點(diǎn)：

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

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

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

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

解決方案

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

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

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

方案特點(diǎn)：

對(duì)于同一個(gè)處理節(jié)點(diǎn)，會(huì)部署在多臺(tái)機(jī)器上，每臺(tái)機(jī)器都可以啟動(dòng)多個(gè)線程來同時(shí)處理該節(jié)點(diǎn)的任務(wù)；

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

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

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

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

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

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

硬件部署：

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

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

總結(jié)

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

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

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