王巍

摘? ?要：在運(yùn)營商某融合通信系統(tǒng)中，傳統(tǒng)的Hadoop海量文件批處理速度慢，數(shù)據(jù)庫面對海量數(shù)據(jù)存儲及全文檢索能力弱，無法應(yīng)對日常運(yùn)維需要。處理海量業(yè)務(wù)日志且提升實(shí)時(shí)性，技術(shù)選型flume+Kafka+Spark+ElasticSearch，改造為流式計(jì)算大數(shù)據(jù)技術(shù)架構(gòu)。文章結(jié)合業(yè)務(wù)訴求，基于領(lǐng)域模型全新設(shè)計(jì)，DashBoard分層遞進(jìn)，漸進(jìn)明細(xì)地實(shí)時(shí)發(fā)現(xiàn)故障—初步分析—根因分析—定界定位，大幅提升系統(tǒng)運(yùn)維運(yùn)營能力和時(shí)效性的同時(shí)，還降低了人力成本。

關(guān)鍵詞：大數(shù)據(jù);智能運(yùn)維;Kafka;Spark;ElasticSearch

運(yùn)營商某融合通信運(yùn)維系統(tǒng)原本選型Hadoop，該技術(shù)架構(gòu)盡管能處理海量業(yè)務(wù)日志，但因?yàn)榛谖募鬏敽蚆apReduce的批處理延遲較大，每批次處理最快也要20 min左右才能入庫查詢。運(yùn)維講求時(shí)效性，業(yè)務(wù)故障后幾分鐘內(nèi)就要及時(shí)發(fā)現(xiàn)并分析定位解決，Hadoop文件批處理技術(shù)架構(gòu)往往在用戶投訴上來后，日志還在下一批次的處理入庫中，無法滿足日常運(yùn)維需要。數(shù)據(jù)庫面對海量日志存儲和各種組合查詢力不從心，同時(shí)，系統(tǒng)業(yè)務(wù)設(shè)計(jì)單一，只有業(yè)務(wù)上報(bào)的告警和日志查詢，運(yùn)維能力過于單薄。

1? ? 架構(gòu)設(shè)計(jì)

針對上述運(yùn)維訴求的痛點(diǎn)，急需設(shè)計(jì)一套能實(shí)時(shí)處理大容量日志、支持海量日志存儲且可組合檢索、貼近運(yùn)維運(yùn)營訴求、統(tǒng)計(jì)分析簡約易用的大數(shù)據(jù)運(yùn)維運(yùn)營系統(tǒng)。

1.1? 邏輯架構(gòu)

首先，從邏輯架構(gòu)出發(fā)，結(jié)合業(yè)務(wù)痛點(diǎn)，逐層梳理設(shè)計(jì)并技術(shù)選型。實(shí)時(shí)流式計(jì)算大數(shù)據(jù)邏輯架構(gòu)如圖1所示。

（1）業(yè)務(wù)數(shù)據(jù)源。原本由自身業(yè)務(wù)系統(tǒng)生成日志文件SFTP定時(shí)采集，改造為日志消息接口實(shí)時(shí)發(fā)送;原本第三方系統(tǒng)生成日志文件SFTP定時(shí)采集，改造為flume或logstash實(shí)時(shí)采集。

（2）分布式消息隊(duì)列集群。該層用于前臺業(yè)務(wù)和后臺運(yùn)維運(yùn)營系統(tǒng)消息異步處理，系統(tǒng)間隔離解耦，同時(shí)避免多套業(yè)務(wù)系統(tǒng)日志對后臺運(yùn)維運(yùn)營系統(tǒng)的流量沖擊，進(jìn)行削峰。最終選型Kafka，因?yàn)镵afka是一個(gè)基于發(fā)布/訂閱模式的分布式消息隊(duì)列，完全滿足上述特性要求，且對記錄2 KB以內(nèi)的日志，單模塊處理性能經(jīng)測試就可達(dá)近10萬TPS，還支持持久化，是業(yè)界實(shí)時(shí)大數(shù)據(jù)日志處理MQ的事實(shí)標(biāo)準(zhǔn)組件。

（3）分布式內(nèi)存流式計(jì)算集群。該層用于從Kafka實(shí)時(shí)消費(fèi)各個(gè)topic的日志數(shù)據(jù)流，進(jìn)行實(shí)時(shí)流式計(jì)算，如實(shí)時(shí)日志清單入庫、實(shí)時(shí)分組統(tǒng)計(jì)多維度的業(yè)務(wù)量、失敗量等可累加指標(biāo);同時(shí)也要具備海量數(shù)據(jù)的批處理能力，用于從持久化到HDFS的數(shù)據(jù)批量計(jì)算不可實(shí)時(shí)統(tǒng)計(jì)的日活用戶排重、top失敗等指標(biāo)。最終選型Spark，因?yàn)镾park是一個(gè)同時(shí)支持流式計(jì)算（Spark Streaming）和批量計(jì)算（SparkSQL/RDD）的大數(shù)據(jù)處理系統(tǒng)，完全滿足上述特性要求，且可無縫對接Kafka和ElasticSearch集群。Spark Streaming相當(dāng)于mini batch的RDD批處理，也就是說流式計(jì)算和批量計(jì)算的開發(fā)方法基本相同，且對各類分組、排序、排重等常用統(tǒng)計(jì)進(jìn)行了函數(shù)封裝，大幅降低了研發(fā)學(xué)習(xí)和開發(fā)成本。業(yè)界也有很多成功應(yīng)用案例。

（4）分布式搜索引擎集群。該層用于存儲海量日志清單，同時(shí)需要支持多維度組合條件查詢分析。最終選型ElasticSearch，因?yàn)镋lasticSearch底層是基于lucence索引的分布式搜索引擎，完全滿足上述特性要求，相對solr可以支持更大數(shù)量級的日志存儲和檢索，提供了各類Rest接口的API，方便進(jìn)行分組、聚合等輕量級快速、靈活查詢分析，還支持全文檢索。業(yè)界也有很多成功應(yīng)用案例。

（5）運(yùn)維運(yùn)營門戶。該層需要結(jié)合業(yè)務(wù)設(shè)計(jì)，DashBoard多維度展現(xiàn)各類統(tǒng)計(jì)分析監(jiān)控指標(biāo)，支持鉆取、聯(lián)動(dòng)分析等。業(yè)界有Grafana、Kibana可以使用。最終選型是自身的Web管理平臺，原因是自身的Web管理平臺還具備權(quán)限管理、操作日志、告警界面展現(xiàn)等，并支持菜單集成掛載鏈接到Grafana，Kibana等。

1.2? 技術(shù)架構(gòu)

在邏輯架構(gòu)和已選型的組件基礎(chǔ)上，進(jìn)行了架構(gòu)細(xì)化、業(yè)務(wù)功能設(shè)計(jì)與組件實(shí)現(xiàn)相對應(yīng)，讓數(shù)據(jù)流在整套系統(tǒng)內(nèi)流轉(zhuǎn)起來，并在實(shí)驗(yàn)室部署調(diào)試驗(yàn)證組件功能和性能，從無到有搭建，小步快跑逐步實(shí)現(xiàn)了整套系統(tǒng)。實(shí)時(shí)流式計(jì)算大數(shù)據(jù)技術(shù)架構(gòu)如圖2所示。

2? ? 業(yè)務(wù)設(shè)計(jì)

2.1? 故障告警專題

告警是運(yùn)維系統(tǒng)監(jiān)控發(fā)現(xiàn)故障問題的重要手段，是整套運(yùn)維系統(tǒng)的最先切入點(diǎn)。

傳統(tǒng)的告警功能是業(yè)務(wù)觸發(fā)告警一一對應(yīng)。本專題設(shè)計(jì)了3層靈活組裝模型：基礎(chǔ)指標(biāo)—組合指標(biāo)—告警策略，只需要向業(yè)務(wù)獲取基礎(chǔ)指標(biāo)。本運(yùn)維系統(tǒng)基于基礎(chǔ)指標(biāo)和算術(shù)表達(dá)式，可靈活定義配置出新的組合指標(biāo);基礎(chǔ)指標(biāo)和組合指標(biāo)又可以任意邏輯組合，靈活定義配置出新的告警策略。舉例如下：

基礎(chǔ)指標(biāo)，每分鐘業(yè)務(wù)量、每分鐘成功數(shù)。

組合指標(biāo)，在運(yùn)維系統(tǒng)配置即可新增“業(yè)務(wù)成功率（%）組合指標(biāo)”=每分鐘成功數(shù)/每分鐘業(yè)務(wù)量×100%。

告警策略，系統(tǒng)配置新增“平日夜間告警策略”。

時(shí)間范圍：周一至周五，22：00—5：30。

優(yōu)先級：1。

告警策略：（每分鐘業(yè)務(wù)量>10）AND（業(yè)務(wù)成功率（%）組合指標(biāo)<95（%）。

可以看出，該專題設(shè)計(jì)大幅減輕了業(yè)務(wù)系統(tǒng)的告警工作，轉(zhuǎn)由本運(yùn)維系統(tǒng)靈活配置快速組裝承載，降低了研發(fā)人力的同時(shí)，還增強(qiáng)了運(yùn)維能力。

2.2? 業(yè)務(wù)質(zhì)量專題

故障告警專題鉆取聯(lián)動(dòng)的下一級是業(yè)務(wù)質(zhì)量專題：當(dāng)運(yùn)維人員發(fā)現(xiàn)系統(tǒng)業(yè)務(wù)告警后，點(diǎn)擊告警，系統(tǒng)自動(dòng)鉆取聯(lián)動(dòng)跳轉(zhuǎn)到對應(yīng)的業(yè)務(wù)質(zhì)量界面，在故障發(fā)生時(shí)間點(diǎn)粒度內(nèi)，結(jié)合界面的時(shí)間趨勢圖等DashBoard，多維度分析，初步判斷故障發(fā)生的業(yè)務(wù)類型、地域、終端類型、終端版本、APP版本等。

2.3? 質(zhì)量分析專題

業(yè)務(wù)質(zhì)量專題鉆取聯(lián)動(dòng)的下一級是質(zhì)量分析專題：運(yùn)維人員在業(yè)務(wù)質(zhì)量對故障發(fā)生的業(yè)務(wù)類型、地域、終端類型、終端版本、APP版本等維度有了初步判斷，界面點(diǎn)擊，系統(tǒng)自動(dòng)鉆取聯(lián)動(dòng)跳轉(zhuǎn)到相同維度的質(zhì)量分析界面，在故障發(fā)生時(shí)間點(diǎn)粒度內(nèi)，對應(yīng)維度的業(yè)務(wù)內(nèi)部錯(cuò)誤碼、外部失敗響應(yīng)碼按出現(xiàn)次數(shù)TOP倒排分析，讓運(yùn)維人員迅速得知故障根因。

2.4? 故障定位專題

質(zhì)量分析專題鉆取聯(lián)動(dòng)的下一級是故障定位專題：運(yùn)維人員在質(zhì)量分析界面點(diǎn)擊出現(xiàn)次數(shù)TOP的業(yè)務(wù)內(nèi)部錯(cuò)誤碼、外部失敗響應(yīng)碼，系統(tǒng)自動(dòng)鉆取聯(lián)動(dòng)跳轉(zhuǎn)到相同維度條件的詳單查詢并自動(dòng)查詢，展現(xiàn)出來受此影響的用戶和波及業(yè)務(wù)詳單記錄，讓客服提前做好準(zhǔn)備解答客戶問題。

2.5? 資源占用專題

儀表盤、時(shí)間趨勢圖實(shí)時(shí)展現(xiàn)當(dāng)前系統(tǒng)各類業(yè)務(wù)資源、緩存資源、CPU、內(nèi)存、存儲資源的占用和訪問情況等。

2.6? 用戶分析專題

運(yùn)維之外，系統(tǒng)還具備分地域、分終端，各APP等維度的已開戶用戶數(shù)，日活、周活、月活用戶數(shù)，當(dāng)前在線用戶數(shù)等用戶運(yùn)營分析指標(biāo)、發(fā)展趨勢、占比分析等。

3? ? 結(jié)語

本大數(shù)據(jù)運(yùn)維運(yùn)營系統(tǒng)目前已在運(yùn)營商某融合通信系統(tǒng)成功上線商用，運(yùn)維人員從擔(dān)心用戶投訴，手工采集日志打包反饋研發(fā)耗時(shí)、耗力，到系統(tǒng)自動(dòng)業(yè)務(wù)告警及時(shí)發(fā)現(xiàn)故障，運(yùn)維人員鉆取聯(lián)動(dòng)自行初步判斷、根因分析、故障定界定位、實(shí)時(shí)監(jiān)測系統(tǒng)和業(yè)務(wù)資源占用等，運(yùn)營人員自助報(bào)表分析用戶行為，大幅提升了運(yùn)維運(yùn)營能力的同時(shí)，從過去的幾十人運(yùn)維團(tuán)隊(duì)降低到10人以內(nèi)，得到了客戶、運(yùn)維、運(yùn)營、研發(fā)的一致認(rèn)可。

[參考文獻(xiàn)]

[1]李祥池.基于ELK和Spark Streaming的日志分析系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].電子科學(xué)技術(shù)，2015（6）：674-678.

[2]毛開梅.大數(shù)據(jù)智能運(yùn)維系統(tǒng)設(shè)計(jì)及應(yīng)用[J].網(wǎng)絡(luò)與信息工程，2018（14）：62-63.

Design and application of big data intelligent operation and maintenance system in operators

Wang Wei

（Zhongxing Telecommunication Equipment Corporation Co.， Ltd.， Nanjing 210012， China）

Abstract：In a converged communication system of the operator， the traditional Hadoop mass file is slow in batch processing speed， and the database faces massive data storage and full-text retrieval capability， so that the daily operation and maintenance needs cannot be met. In order to deal with the massive business log and improve the real-time performance， the technology type-type flume+Kafka+Spark+ElasticSearch is transformed into a stream-type large-scale data technology architecture in this paper. Based on the new design of the domain model and the new design of the domain model， the real-time discovery of the DashBoard hierarchical progression and the progressive details is based on the analysis of the position of the analytic hierarchy， and the operation and maintenance of the system is greatly improved. While operating ability and timeliness， it also reduces the cost of manpower.

Key words：big data; intelligent operation and maintenance; Kafka; Spark; ElasticSearch