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

李杰 張攀翔

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

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

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

1 告警信息的壓縮

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

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

（2）如何快速從大量告警中找到故障根源。

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

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

2 告警故障樹自動化分析

如何快速從大量告警中找到故障根源，采用故障樹分析方法，從告警源頭按照安全手冊，利用運維經(jīng)驗和故障案例，設(shè)定每個推理節(jié)點的判決條件，當(dāng)告警信息出現(xiàn)時，利用故障樹自動化分析平臺，實現(xiàn)故障告警的預(yù)處理，協(xié)助運維人員快速找到故障根源。

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

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

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

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

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

原則四：驗證規(guī)則，根據(jù)經(jīng)驗和知識庫來定。

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

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

3 引入了消息隊列機制，確保故障信息不丟失

為何要引入消息隊列？因為基站的告警信息太多的時候，可能會因為后端處理能力不足，造成告警信息遺落，為了不丟失告警信息，這里我們采用kafka進行告警的緩存，避免還沒來得及被消費的告警信息丟失。如圖4所示。

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

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

Kafka主要特點：

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

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

分布式系統(tǒng)，易于向外擴展。所有的producer、broker和consumer都會有多個，均為分布式的。無需停機即可擴展機器。

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

支持online和offline的場景。

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

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

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

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

（1）能運行在100+的結(jié)點上，并達到秒級延遲。

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

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

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

5 總結(jié)

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

參考文獻

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

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

作者單位

中國移動通信集團廣東有限公司 廣東省廣州市 510623