鐵路視頻監控專業化運維平臺設計與實現

楊栩

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

關鍵詞：云平臺? 云存儲? 微服務? 自動化運維

1? 既有鐵路綜合視頻網管系統現狀分析

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

2? 專業化視頻運維平臺總體設計

2.1 總體框架

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

2.2 高可用方案

（1）基礎架構為LAMP環境，采用keepalived實現zabbix服務器高可用，保證主server的mysql或者httpd宕掉后能切換到從server。（2）數據庫做主同步，保證兩邊服務器數據的一致性，實現數據庫的高可用。（3）采用unison同步軟件保證不管修改那臺服務器配置，zabbix配置目錄及web目錄內容的一致，實現文件雙向同步。

3? 平臺實現

3.1 基礎監控數據采集

3.1.1 支持多種協議數據采集

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

3.1.2 豐富的監控指標

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

3.2 運維監控業務

3.2.1 監控對象資產管理與告警規則管理

綜合視頻云系統中的基礎設備和業務流中的軟件服務、中間件、數據庫。基礎設施包括：攝像機、服務器、交換機、磁盤陣列、電源控制箱等。

告警規則如表1所示。

3.2.2 故障根因分析

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

3.2.3 故障處理業務流程

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

3.2.4 故障預警

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

3.2.5 簡單故障自愈

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

4? 工程實施

4.1 性能調優

運維平臺每天都會產生大量的監控數據，系統性能瓶頸往往取決于數據存儲。為此，我們實施了以下優化方案。硬件方面采用固態硬盤存儲數據。軟件方面采用調整數據庫性能參數配置、歷史數據表分區分表等手段優化數據庫性能。此外，我們還對收集到的數據進行二次過濾篩選，過濾掉沒有發生變化或變化幅度低于1%的監控數據。

4.2 容器化部署

容器化可實現應用隔離，某個服務消耗資源不會占用其他應用資源。利用docker實現自動部署，自動重啟，自動復制，自動伸縮擴展。部署docker應用，省去依賴環境的配置。鏡像倉庫服務，本地打包好上傳，服務器直接拉取即可。

5? 應用案例

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

系統主界面如圖3所示，為用戶提供京張全線視頻系統實時軟硬件運維監控指標大數據，用戶直觀了解全線攝像機、視頻微服務的工作狀態、存儲空間使用狀況、網絡流量狀態、服務器內部主要元器件工作狀態、視頻圖像質量診斷數據等。用戶通過點擊主頁上的站點，能夠跳轉到具體站點的軟硬件設施監實時詳細監控數據展示頁面，例如云平臺微服務工作狀態、服務器電源狀態、CPU溫度、內存使用率、網絡流量帶寬、交換機端口工作狀態等。

6? 結語

面向下一代運維平臺，我們將引入深度學習、貝葉斯網絡等人工智能技術深度挖掘故障內部蘊含的關聯關系，加大告警收斂力度;進一步強化故障自愈功能降低運維人工干預成本;提升故障預測精準確度，為用戶提供更加及時準確可靠的故障預警和存儲容量規劃信息。

參考文獻

[1] 簡單網絡管理協議教程[Z].

[2] QCR 575-2017 鐵路視頻監控系統技術規范[Z].

[3] Zabbix企業級分布式監控系統[Z].

[4] ITIL3.0技術白皮書[Z].