一種基站告警的預(yù)處理方法

李杰 張攀翔

摘 要 伴隨當(dāng)今通信技術(shù)的日益發(fā)展與完備，通信市場(chǎng)領(lǐng)域開始出現(xiàn)日漸激烈的競(jìng)爭(zhēng)，對(duì)移動(dòng)運(yùn)營(yíng)商網(wǎng)絡(luò)性能要求也越來(lái)越高，而在整個(gè)移動(dòng)網(wǎng)絡(luò)系統(tǒng)中，為用戶提供接入服務(wù)的基站系統(tǒng)占據(jù)著重要地位。而基站的保障和高效運(yùn)行，關(guān)鍵在于如何高效處理基站告警。

【關(guān)鍵詞】基站告警準(zhǔn)實(shí)時(shí)統(tǒng)一監(jiān)控 基站告警預(yù)處理決策樹

隨著業(yè)務(wù)的發(fā)展，基站的運(yùn)維管理越來(lái)越自動(dòng)化，在各種的自動(dòng)化監(jiān)控告警設(shè)備的加入，針對(duì)基站的告警信息越來(lái)越多，如何高效的管理這些告警信息，避免日常的運(yùn)維陷入海量告警的汪洋之中，是本文要討論的要點(diǎn) 。

1 告警信息的壓縮

越來(lái)越多的自動(dòng)化設(shè)備產(chǎn)生的監(jiān)控告警，在大量告警風(fēng)暴來(lái)臨的情況下，要解決以下2個(gè)重要問(wèn)題：

（1）如何在告警風(fēng)暴時(shí)壓縮告警；

（2）如何快速?gòu)拇罅扛婢姓业焦收细础?/p>

壓縮告警風(fēng)暴，可采用按照告警重要程度進(jìn)行壓縮，基站故障告警信息按照重要緊急程度可分為一般不緊急告警、一般緊急告警、重要不緊急告警、重要緊急告警四大類，首先從告警的重要緊急程度收斂告警信息。

其次，告警信息是分層次的， 每一層的告警又可分為原子告警，衍生性告警。因此，故障告警的報(bào)告，以重要性從最高層往最低層報(bào)，每層中重要性從原子告警到衍生性告警報(bào)，從而減少告警風(fēng)暴。如圖1所示。

2 告警故障樹自動(dòng)化分析

如何快速?gòu)拇罅扛婢姓业焦收细矗捎霉收蠘浞治龇椒?，從告警源頭按照安全手冊(cè)，利用運(yùn)維經(jīng)驗(yàn)和故障案例，設(shè)定每個(gè)推理節(jié)點(diǎn)的判決條件，當(dāng)告警信息出現(xiàn)時(shí)，利用故障樹自動(dòng)化分析平臺(tái)，實(shí)現(xiàn)故障告警的預(yù)處理，協(xié)助運(yùn)維人員快速找到故障根源。

故障樹分析（Fault Tree Analysis，簡(jiǎn)稱FTA）又稱事故樹分析，是安全系統(tǒng)工程中最重要的分析方法。事故樹分析從一個(gè)可能的事故開始，自上而下、一層層的尋找頂事件的直接原因和間接原因事件，直到基本原因事件，并用邏輯圖把這些事件之間的邏輯關(guān)系表達(dá)出來(lái)。

構(gòu)建基站故障樹分析的原則有以下：

原則一：告警從高層向底層，在邏輯層次上面，越根源性的告警越先判斷。

原則二：從原子到衍生告警。

原則三：推理樹的建立根據(jù)告警來(lái)定。

原則四：驗(yàn)證規(guī)則，根據(jù)經(jīng)驗(yàn)和知識(shí)庫(kù)來(lái)定。

以IP相關(guān)的告警為例（如圖2所示）。

當(dāng)創(chuàng)建的故障樹越全面的時(shí)候，對(duì)故障信息的預(yù)處理則越準(zhǔn)確，為了準(zhǔn)實(shí)時(shí)的自動(dòng)化處理告警信息，使用spark streaming+hadoop處理告警和存儲(chǔ)告警，整個(gè)基站告警信息預(yù)處理的框架如圖3所示。

3 引入了消息隊(duì)列機(jī)制，確保故障信息不丟失

為何要引入消息隊(duì)列？因?yàn)榛镜母婢畔⑻嗟臅r(shí)候，可能會(huì)因?yàn)楹蠖颂幚砟芰Σ蛔?，造成告警信息遺落，為了不丟失告警信息，這里我們采用kafka進(jìn)行告警的緩存，避免還沒來(lái)得及被消費(fèi)的告警信息丟失。如圖4所示。

Kafka is a distributed，partitioned，replicated commit logservice。它提供了類似于JMS的特性，但是在設(shè)計(jì)實(shí)現(xiàn)上完全不同，此外它并不是JMS規(guī)范的實(shí)現(xiàn)。kafka對(duì)消息保存時(shí)根據(jù)Topic進(jìn)行歸類，發(fā)送消息者成為Producer，消息接受者成為Consumer，此外kafka集群有多個(gè)kafka實(shí)例組成，每個(gè)實(shí)例（server）成為broker。無(wú)論是kafka集群，還是producer和consumer都依賴于zookeeper來(lái)保證系統(tǒng)可用性集群保存一些meta信息。

kafka即使消息被消費(fèi)，消息仍然不會(huì)被立即刪除，日志文件將會(huì)根據(jù)broker中的配置要求，保留一定的時(shí)間之后刪除，從根本上保障了告警信息的安全。

Kafka主要特點(diǎn)：

同時(shí)為發(fā)布和訂閱提供高吞吐量。據(jù)了解，Kafka每秒可以生產(chǎn)約25萬(wàn)消息（50 MB），每秒處理55萬(wàn)消息（110 MB）。

可進(jìn)行持久化操作。將消息持久化到磁盤，因此可用于批量消費(fèi)，例如ETL，以及實(shí)時(shí)應(yīng)用程序。通過(guò)將數(shù)據(jù)持久化到硬盤以及replication防止數(shù)據(jù)丟失。

分布式系統(tǒng)，易于向外擴(kuò)展。所有的producer、broker和consumer都會(huì)有多個(gè)，均為分布式的。無(wú)需停機(jī)即可擴(kuò)展機(jī)器。

消息被處理的狀態(tài)是在consumer端維護(hù)，而不是由server端維護(hù)。當(dāng)失敗時(shí)能自動(dòng)平衡。

支持online和offline的場(chǎng)景。

4 使用spark streaming+hadoop處理告警信息

如圖5所示，使用Spark流處理告警信息，包括對(duì)告、消除告警等操作，這里使用spark的好處在于吞吐量高，容易維護(hù)。

Spark是一個(gè)類似于MapReduce的分布式計(jì)算框架，其核心是彈性分布式數(shù)據(jù)集，提供了比MapReduce更豐富的模型，可以在快速在內(nèi)存中對(duì)數(shù)據(jù)集進(jìn)行多次迭代，以支持復(fù)雜的數(shù)據(jù)挖掘算法和圖形計(jì)算算法。Spark Streaming是一種構(gòu)建在Spark上的實(shí)時(shí)計(jì)算框架，它擴(kuò)展了Spark處理大規(guī)模流式數(shù)據(jù)的能力。如圖6所示。

Spark Streaming的優(yōu)勢(shì)在于：

（1）能運(yùn)行在100+的結(jié)點(diǎn)上，并達(dá)到秒級(jí)延遲。

（2）使用基于內(nèi)存的Spark作為執(zhí)行引擎，具有高效和容錯(cuò)的特性。

（3）能集成Spark的批處理和交互查詢。

（4）為實(shí)現(xiàn)復(fù)雜的算法提供和批處理類似的簡(jiǎn)單接口。

5 總結(jié)

綜上所述，搭建一個(gè)自動(dòng)化基站告警預(yù)處理平臺(tái)，將告警按照重要緊急程度進(jìn)行壓縮，盡量減少衍生性告警，突出原子性告警，使用運(yùn)維經(jīng)驗(yàn)和故障手冊(cè)創(chuàng)建豐富的故障分析樹模型，在spark當(dāng)中自動(dòng)化分析查找告警的根源。利用kafka保障告警信息的高可用性，結(jié)合spark在流處理實(shí)現(xiàn)基站告警的自動(dòng)化分析，每一條告警推送到運(yùn)維人員之前，就已經(jīng)通過(guò)機(jī)器算法尋找到故障根源，減少運(yùn)維人員重復(fù)機(jī)械的勞動(dòng)，協(xié)助運(yùn)維人員快速尋找基站故障的根源和解除基站故障告警。

參考文獻(xiàn)

[1]甄云恒.基站告警監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].大連理工大學(xué)，2013.

[2]姚仁捷.Kafka在唯品會(huì)的應(yīng)用實(shí)踐[D].云計(jì)算，2014.

作者單位

中國(guó)移動(dòng)通信集團(tuán)廣東有限公司 廣東省廣州市 510623