楊栩

摘? ?要：本文分析了既有鐵路視頻網(wǎng)管系統(tǒng)無法滿足云系統(tǒng)、云存儲運(yùn)維監(jiān)控要求的現(xiàn)狀，通過云計(jì)算、微服務(wù)、zabbix自動化運(yùn)維平臺等新技術(shù)的運(yùn)用，提出了全新的整體解決方案，對綜合視頻云系統(tǒng)中的基礎(chǔ)設(shè)施和主要應(yīng)用服務(wù)進(jìn)行全方位運(yùn)維監(jiān)控。該平臺已在京張高鐵上運(yùn)營實(shí)施并收到了良好效果。

關(guān)鍵詞：云平臺? 云存儲? 微服務(wù)? 自動化運(yùn)維

1? 既有鐵路綜合視頻網(wǎng)管系統(tǒng)現(xiàn)狀分析

隨著鐵路綜合視頻監(jiān)控系統(tǒng)逐步向云平臺升級，用戶對云平臺的運(yùn)維監(jiān)控需求愈發(fā)強(qiáng)烈，然而現(xiàn)有的鐵路綜合視頻網(wǎng)管運(yùn)維系統(tǒng)已經(jīng)無法承載集群化的軟硬件設(shè)施監(jiān)控業(yè)務(wù)，無法對云系統(tǒng)的整體運(yùn)行狀況和集群內(nèi)部的微服務(wù)運(yùn)行狀態(tài)進(jìn)行監(jiān)控。此外，傳統(tǒng)的網(wǎng)管系統(tǒng)缺乏故障定位根因分析、故障自愈、存儲容量預(yù)測、故障閉環(huán)處理等功能;不僅如此，傳統(tǒng)的網(wǎng)管系統(tǒng)過多依賴于snmp協(xié)議[1]作為監(jiān)控?cái)?shù)據(jù)采集接口，導(dǎo)致監(jiān)控各種型號的硬件設(shè)施都需做大量的適配工作，這些問題都極大地增加了運(yùn)維成本。因此，如何設(shè)計(jì)構(gòu)建智能化、高可用的鐵路綜合視頻專業(yè)運(yùn)維平臺是本文的主要研究內(nèi)容。

2? 專業(yè)化視頻運(yùn)維平臺總體設(shè)計(jì)

2.1 總體框架

本系統(tǒng)采用從底層運(yùn)行支撐到上層業(yè)務(wù)運(yùn)行的全棧集中監(jiān)控設(shè)計(jì)理念，對基礎(chǔ)設(shè)備設(shè)施、應(yīng)用服務(wù)、傳輸網(wǎng)絡(luò)、數(shù)據(jù)庫、中間件全覆蓋監(jiān)控。系統(tǒng)將收集到的監(jiān)控?cái)?shù)據(jù)，依據(jù)告警規(guī)則閾值判定產(chǎn)生故障告警消息，并對告警消息進(jìn)行根因分析甄別出故障的根本原因，將經(jīng)過篩選后的故障告警消息推送給鐵路電務(wù)通信運(yùn)維人員。運(yùn)維人員將處理后結(jié)果記錄到系統(tǒng)中形成問題檔案庫以備將來遇到同類問題時(shí)方便查閱。

2.2 高可用方案

（1）基礎(chǔ)架構(gòu)為LAMP環(huán)境，采用keepalived實(shí)現(xiàn)zabbix服務(wù)器高可用，保證主server的mysql或者h(yuǎn)ttpd宕掉后能切換到從server。（2）數(shù)據(jù)庫做主同步，保證兩邊服務(wù)器數(shù)據(jù)的一致性，實(shí)現(xiàn)數(shù)據(jù)庫的高可用。（3）采用unison同步軟件保證不管修改那臺服務(wù)器配置，zabbix配置目錄及web目錄內(nèi)容的一致，實(shí)現(xiàn)文件雙向同步。

3? 平臺實(shí)現(xiàn)

3.1 基礎(chǔ)監(jiān)控?cái)?shù)據(jù)采集

3.1.1 支持多種協(xié)議數(shù)據(jù)采集

為了滿足鐵路綜合視頻云平臺中的攝像機(jī)、服務(wù)器、交換機(jī)、磁盤陣列、電源控制箱等基礎(chǔ)硬件設(shè)施以及應(yīng)用服務(wù)的監(jiān)控需求。本平臺提供了支持snmp、ipmi、jmx、http、ssh、telnet、icmp、modbus等多種協(xié)議的數(shù)據(jù)采集方式[3]。

3.1.2 豐富的監(jiān)控指標(biāo)

在滿足《鐵路視頻監(jiān)控系統(tǒng)技術(shù)規(guī)范》[2]的運(yùn)維相關(guān)要求基礎(chǔ)之上，本系統(tǒng)還提供了更加豐富的監(jiān)控指標(biāo)。攝像機(jī)監(jiān)控包括：主子碼流的碼率、幀率、分辨率、關(guān)鍵幀間隔、設(shè)備在線狀態(tài)。服務(wù)器監(jiān)控包括：電源狀態(tài)、硬盤狀態(tài)、磁盤存儲容量、風(fēng)扇轉(zhuǎn)速、CPU溫度、CPU使用率、內(nèi)存使用率、網(wǎng)口工作狀態(tài)、網(wǎng)口帶寬、端口帶寬、端口類型、接收發(fā)送流量、丟包率、設(shè)備在線狀態(tài)。交換機(jī)監(jiān)控包括：端口帶寬、端口工作狀態(tài)、端口類型、接收發(fā)送流量、丟包率、設(shè)備在線狀態(tài)。磁盤陣列監(jiān)控包括：磁盤容量、設(shè)備在線狀態(tài)。電源控制箱監(jiān)控包括：電源、斷路器工作狀態(tài)。云平臺監(jiān)控指標(biāo)監(jiān)控包括：視頻接入、分發(fā)、存儲等微服務(wù)的在線狀態(tài)、各節(jié)點(diǎn)負(fù)載、云平臺總負(fù)載。云存儲監(jiān)控指標(biāo)包括：整體健康度、存儲容量、讀寫帶寬、osd節(jié)點(diǎn)總數(shù)以及單節(jié)點(diǎn)狀態(tài)、對象網(wǎng)關(guān)狀態(tài)。數(shù)據(jù)庫監(jiān)控指標(biāo)監(jiān)控包括：慢查詢個(gè)數(shù)、每秒收發(fā)字節(jié)數(shù)、每秒增刪改執(zhí)行次數(shù)。

3.2 運(yùn)維監(jiān)控業(yè)務(wù)

3.2.1 監(jiān)控對象資產(chǎn)管理與告警規(guī)則管理

綜合視頻云系統(tǒng)中的基礎(chǔ)設(shè)備和業(yè)務(wù)流中的軟件服務(wù)、中間件、數(shù)據(jù)庫。基礎(chǔ)設(shè)施包括：攝像機(jī)、服務(wù)器、交換機(jī)、磁盤陣列、電源控制箱等。

告警規(guī)則如表1所示。

3.2.2 故障根因分析

由于不同類型故障告警之間存在一定的因果關(guān)聯(lián)關(guān)系，本系統(tǒng)將設(shè)備之間、故障類型之間的故障因果關(guān)聯(lián)關(guān)系提前預(yù)設(shè)形成專家?guī)?，告警收斂模塊運(yùn)用專家?guī)鞂?shí)現(xiàn)業(yè)務(wù)全鏈路追蹤找到故障根源，從而過濾掉大量衍生告警，初步達(dá)到智能化運(yùn)維的效果。例如，可以將以下兩種情形納入到故障關(guān)聯(lián)關(guān)系專家?guī)?。情形一：錄像斷點(diǎn)與網(wǎng)管攝像機(jī)、服務(wù)、云存儲告警關(guān)聯(lián)情況， 自動分析出錄像出現(xiàn)斷點(diǎn)時(shí)段內(nèi)是否存在攝像機(jī)離線、服務(wù)離線、云存儲異常等告警，進(jìn)一步分析路線斷點(diǎn)的根本原因是哪類故障造成的。情形二：定義交換機(jī)離線、服務(wù)器網(wǎng)口故障、攝像機(jī)離線三類故障之間的因果關(guān)系。

3.2.3 故障處理業(yè)務(wù)流程

當(dāng)故障告警生成之后就需要運(yùn)維人員來處理這些告警。我們依據(jù)ITIL規(guī)范技術(shù)流程設(shè)計(jì)故障處理工作流業(yè)務(wù)模型，實(shí)現(xiàn)申告、受理、派單、處理、審核、關(guān)閉一整套閉環(huán)管理[4]。系統(tǒng)將告警與故障工單建立關(guān)聯(lián)關(guān)系，某個(gè)多某些告警形成一個(gè)故障工單，當(dāng)處理完故障單之后，要檢查該問題單相關(guān)的告警是否已經(jīng)恢復(fù)，如果全部恢復(fù)，則關(guān)閉該問題單，否則繼續(xù)處理，直至問題恢復(fù)才能結(jié)束整個(gè)故障處理流程。同時(shí)，要求故障處理人員把問題原因、處理辦法、處理效果用文字記錄下來，最終形成故障處理知識庫以便運(yùn)維人員查閱。

3.2.4 故障預(yù)警

對于一些可預(yù)測的監(jiān)控指標(biāo)來說，為用戶提供故障預(yù)警分析達(dá)到防患于未然的目的具有更高的實(shí)用價(jià)值。最典型的例子就是磁盤剩余存儲空間預(yù)警。我們對收集到的歷史監(jiān)控?cái)?shù)據(jù)采用指數(shù)平滑、N次多項(xiàng)式等預(yù)測模型對存儲空間剩余容量進(jìn)行預(yù)測，判斷未來還有多長時(shí)間達(dá)到存儲上限告警閾值。

3.2.5 簡單故障自愈

對于一些常見的系統(tǒng)故障或應(yīng)用服務(wù)軟件故障來說，可利用自動化故障恢復(fù)腳本，實(shí)現(xiàn)故障自動恢復(fù)，節(jié)省人工維護(hù)成本。例如，服務(wù)器硬盤拔出插回，云存儲應(yīng)用服務(wù)中的osd節(jié)點(diǎn)離線等故障就可以調(diào)用預(yù)先編制好的故障處理腳本自動消除告警。當(dāng)然，故障自愈作為一種運(yùn)維輔助手段來講只能處理一些簡單且排查方式較為固化的問題，當(dāng)自愈程序無法排除故障時(shí)，系統(tǒng)會把問題單推送給人工干預(yù)處理。

4? 工程實(shí)施

4.1 性能調(diào)優(yōu)

運(yùn)維平臺每天都會產(chǎn)生大量的監(jiān)控?cái)?shù)據(jù)，系統(tǒng)性能瓶頸往往取決于數(shù)據(jù)存儲。為此，我們實(shí)施了以下優(yōu)化方案。硬件方面采用固態(tài)硬盤存儲數(shù)據(jù)。軟件方面采用調(diào)整數(shù)據(jù)庫性能參數(shù)配置、歷史數(shù)據(jù)表分區(qū)分表等手段優(yōu)化數(shù)據(jù)庫性能。此外，我們還對收集到的數(shù)據(jù)進(jìn)行二次過濾篩選，過濾掉沒有發(fā)生變化或變化幅度低于1%的監(jiān)控?cái)?shù)據(jù)。

4.2 容器化部署

容器化可實(shí)現(xiàn)應(yīng)用隔離，某個(gè)服務(wù)消耗資源不會占用其他應(yīng)用資源。利用docker實(shí)現(xiàn)自動部署，自動重啟，自動復(fù)制，自動伸縮擴(kuò)展。部署docker應(yīng)用，省去依賴環(huán)境的配置。鏡像倉庫服務(wù)，本地打包好上傳，服務(wù)器直接拉取即可。

5? 應(yīng)用案例

本系統(tǒng)于2019年12月在京張高鐵上首次投入使用。服務(wù)器54臺、交換機(jī)94臺、攝像機(jī)3706部、攝像機(jī)電源控制箱60余個(gè)。云平臺1套、云存儲集群8套、MySQL數(shù)據(jù)庫、消息隊(duì)列服務(wù)1個(gè)、HTTP服務(wù)1個(gè)。

系統(tǒng)主界面如圖3所示，為用戶提供京張全線視頻系統(tǒng)實(shí)時(shí)軟硬件運(yùn)維監(jiān)控指標(biāo)大數(shù)據(jù)，用戶直觀了解全線攝像機(jī)、視頻微服務(wù)的工作狀態(tài)、存儲空間使用狀況、網(wǎng)絡(luò)流量狀態(tài)、服務(wù)器內(nèi)部主要元器件工作狀態(tài)、視頻圖像質(zhì)量診斷數(shù)據(jù)等。用戶通過點(diǎn)擊主頁上的站點(diǎn)，能夠跳轉(zhuǎn)到具體站點(diǎn)的軟硬件設(shè)施監(jiān)實(shí)時(shí)詳細(xì)監(jiān)控?cái)?shù)據(jù)展示頁面，例如云平臺微服務(wù)工作狀態(tài)、服務(wù)器電源狀態(tài)、CPU溫度、內(nèi)存使用率、網(wǎng)絡(luò)流量帶寬、交換機(jī)端口工作狀態(tài)等。

6? 結(jié)語

面向下一代運(yùn)維平臺，我們將引入深度學(xué)習(xí)、貝葉斯網(wǎng)絡(luò)等人工智能技術(shù)深度挖掘故障內(nèi)部蘊(yùn)含的關(guān)聯(lián)關(guān)系，加大告警收斂力度;進(jìn)一步強(qiáng)化故障自愈功能降低運(yùn)維人工干預(yù)成本;提升故障預(yù)測精準(zhǔn)確度，為用戶提供更加及時(shí)準(zhǔn)確可靠的故障預(yù)警和存儲容量規(guī)劃信息。

參考文獻(xiàn)

[1] 簡單網(wǎng)絡(luò)管理協(xié)議教程[Z].

[2] QCR 575-2017 鐵路視頻監(jiān)控系統(tǒng)技術(shù)規(guī)范[Z].

[3] Zabbix企業(yè)級分布式監(jiān)控系統(tǒng)[Z].

[4] ITIL3.0技術(shù)白皮書[Z].