基于Zabbix的鐵路動車組WiFi運營服務監控系統應用研究

高 鵬

（中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081 ）

隨著互聯網的快速發展，以及云計算、大數據、區塊鏈的大規模應用，服務器集群節點數量成倍增加，業務系統變得越來越復雜，一個系統往往由多個應用組成，導致運維難度逐漸加大。傳統運維方式中，運維人員疲于處理各種故障，效率低下，即使加班加點的調試、部署、維護，也經常會因設備故障而導致業務中斷，嚴重影響系統正常運轉。鐵路動車組W iFi運營服務系統通過運營商撥號方式實現互聯網接入，其網絡環境復雜，穩定性差且無固定公網IP，無法直接實現全系統的集中化監控與管理[1]。盡管目前市場上有較多的開源監控系統產品，如：Nagios、Cacti、Zenoss等，一定程度上提高了運維效率，節約了運維成本，但其服務對象相對單一，可定制性差，無法滿足日益增長的企業級服務發展需求，而開源監控方案Zabbix依據其強大的展現功能和可擴展性，加上獨特的開源性和簡單易用等特點,更適用于鐵路動車組W iFi運營服務綜合監控系統[2]。

本文圍繞鐵路動車組W iFi運營服務系統實際部署環境及應用場景，提出了基于Zabbix的鐵路動車組W iFi運營服務監控系統方案。該方案通過整合、分析系統資源，實現從物理資源到系統虛擬資源、端到端的全方位立體化監控，解決了大批量車載W iFi服務器監控難、實時性差以及故障告警不敏捷等問題，滿足了系統運維人員的運維需求，并構建了獨立的集成化Web系統，完成了對鐵路動車組W iFi運營服務系統資源的綜合監控與管理，同時提供可視化的配置支持。

1 監控系統概述

1.1 監控系統場景分析

鐵路動車組W iFi運營服務系統主要由運營管理中心、地面網絡和車載局域網3部分組成，其網絡結構主要包括互聯網接入和車載局域網兩部分[3]，系統結構示意圖如圖1所示。

互聯網接入作為整個動車組W iFi運營服務系統的互聯網出口，通過車頂3G/4G天線與鐵路沿線運營商公網基站建立無線連接通道；車載局域網為車廂內用戶終端和單車設備之間提供車內通信網絡，車內用戶終端可共享車載無線局域網系統的內容服務，車廂單車之間通過車載局域網實現互聯互通[4]。

1.2 監控系統需求分析

2017年6 月，首列“復興號”標動列車正式上線運營，鐵路動車組W iFi運營服務系統作為“復興號”標動列車的配套設施也隨之面世，旅客乘車期間可以享受鐵路動車組W iFi這一增值服務。隨著大批量標動“復興號”列車投入運營，鐵路動車組W iFi運營服務體系規模不斷擴大，其運營管理上亟需實現實時掌控系統運行狀態、監控系統突發事件，以動態調整運營策略，進而實現鐵路動車組W iFi運營服務價值最大化。為滿足動車組W iFi運營服務需求，根據鐵路動車組W iFi運營服務系統業務架構，構建基于Zabbix的車-車、車-地、地-地一體化綜合監控系統平臺[5]，分別從鐵路動車組W iFi運營服務系統硬件層面、系統層面、業務層面進行需求分析，以實現對不同層次粒度數據的采集與融合。

圖1 鐵路動車組WiFi運營服務系統結構圖

2 監控系統部署方案

2.1 部署原理分析

Zabbix作為一套完備的服務器主機監控解決方案，通過對物理設備和系統應用參數的采集分析，建立靈活的多級預警通知機制，使系統故障得到實時響應，并以前端W eb或媒介推送形式進行報告和統計[6]。Zabbix系統框架主要由數據采集部分（客戶端Agentdd）和數據分析告警展示部分（服務端Server）兩部分構成。Agentdd端數據的采集模式又分為主動模式（客戶端主動上報數據到服務端）和被動模式（服務端到客戶端采集數據）。Zabbix_ Agentdd啟動時，會根據服務端設定的采樣間隔向Zabbix_Server請求監控項，通過監控系統預設端口將監控數據項傳送給服務器。Zabbix監控原理如圖2所示。

2.2 監控系統部署架構

圖2 監控系統原理圖

基于鐵路動車組W iFi運營服務系統服務節點分散、規模大等特性，Zabbix監控系統采用主動式上報模式對終端數據項進行采集，以減少監控系統服務端的請求壓力?；趧榆嚱MW iFi運營服務系統應用場景的特殊性，為保障系統數據安全，防止攻擊者利用諸如SQL注入等方式攻擊Zabbix數據庫獲取敏感數據或繞過授權登錄步驟獲取服務器操作系統權限等入侵隱患，Zabbix監控系統將Zabbix _Server部署在客票系統內部專網（簡稱：內網）環境中，所有服務必須經過客票系統12306.cn域名以及應用負載轉發，確保鐵路動車組W iFi運營服務的穩定性與安全性。Zabbix_Server將終端被監控機器的相關監控數據在M YSQL中持久化儲存[7]，便于后續的數據處理和重用。基于Zabbix的鐵路動車組W iFi運營服務監控系統部署架構如圖3所示。

2.3 監控系統關鍵技術

2.3.1 高性能網絡數據包緩存與轉發

基于鐵路動車組具有配屬局分散、不集中等特性，為避免鐵路動車組W iFi運營服務監控系統的Zabbix_Server端無法承受來自終端Zabbix_Agentdd頻繁請求壓力，Zabbix監控系統以列為單位，將列車采集數據集中到同一數據緩存節點，Zabbix_AAgentd在該緩存節點拿取數據，以主動上報方式傳到Zabbix_Serve端。該監控系統設定車載中心服務器作為每列車的數據緩存節點，在其部署Zabbix_Agentd，并配置對應列車的Host_nam e。各車廂單車服務器及AP產生的數據集中到車載W iFi接入控制器（AC）上，車載AC將接收到的數據集中于車載中心服務器基于分布式文件儲存的數據庫（m ongoDB）中存儲,數據以設備ID分類羅列。如圖4所示，M ongoDB中展示了ID為“ZTC-01-000BABDF3355（設備生產商編號-設備類型編號-設備M AC）”中心路由器上報的參數。Zabbix_AAgen td可直接從M ongoDB中調集參數上報給Zabbix_Server端，這種上報方式減少了Zabbix _Agentd部署節點數量，緩解了Zabbix _Server端的處理壓力，對動車組W iFi運營服務監控系統后續性能的擴展有著重要意義，提升了監控系統平臺的實時性和穩定性。

2.3.2 通信協議轉換

圖3 監控系統部署架構圖

鐵路動車組W iFi運營服務系統涉及諸多旅客私密信息，為保障Zabbix 監控系統服務端數據的安全性，將Zabbix_Server從原有的公網阿里云端遷移到客票系統內網部署。內網對于通信協議有嚴格的限制，客票系統內網防火墻只允許來自CDN的HTTP請求通過，而Zabbix監控系統默認通信協議為TCP[8]，這種基于安全防護設計下的監控模式無法使監控數據項通過防火墻上報給Zabbix_Server。本監控系統通過設計TCP/HTTP橋接器，將Zabbix_Server與Zabbix_Agentd之間的通信通過HTTP橋接起來。即將原有C/S結構軟件的數據由“SERVER<-TCP->CLIENT”轉為“SERVER<-TCP->BRIDGE<-HTTP->BRIDGE<-TCP->CLIENT”，其工作流程如下：

（1）Zabbix_Agentd發起TCP請求，請求獲取“active items”，Agentd橋接器監聽到此TCP請求；

（2）Agentd端橋接器將接受的TCP請求數據（byte[] 數組類型）通過Base64編碼，以HTTP方式（Post/Get請求）送到Server端橋接器；

（3）Server端橋接器收到請求數據，將數據解碼還原成Byte類型數組，以TCP方式發送到Zabbix Server端，Zabbix_ Server端返回TCP響應，Server橋接器獲得響應數據，并將響應數據經過Base64編碼處理后以HTTP方式發送回Agentd端橋接器；

（4）Agentd端橋接器將返回數據還原成Byte類型數組，以TCP方式響應給Zabbix_Agentd, Zabbix_Agentd獲取響應，解析返回的字符串，完成一次橋接通信，斷開Socket。

2.3.3 日志集中檢索與全鏈路追蹤技術

鐵路動車組W iFi運營服務系統內部服務應用眾多，部署機器數量較大，平臺每天將產生大量日志數據（約2 000萬條），當用戶業務訪問出現異常時，快速定位并分析問題極為困難。日志分析平臺將所有機器、應用實例所產生的日志由日志采集代理收集并傳輸至平臺進行存儲、建立索引并提供日志檢索服務。對于每個用戶終端請求統一分配全平臺范圍內的唯一追蹤ID，根據此唯一追蹤ID即可實現對用戶請求處理過程的全鏈路追蹤，同時，結合日志時間戳可以分析用戶請求處理過程中每個處理步驟的耗時情況，并繪制服務處理時序圖與服務調用關系圖，幫助研發人員快速定位，分析問題。日志集中分析平臺從日志產生到提供檢索延時不超過5 s，平均檢索耗時在3 s以內，為研發與運維人員提供了強有力的故障定位工具，同時，也是平臺運行狀況監控的重要數據源。

圖4 MongoDB 數據儲存列表

3 監控系統實現

3.1 運營統計模塊實現

Zabbix監控系統通過自定義腳本對車載中心服務器路由板網卡的流量消耗實時性監控，Zabbix_Server端通過對消耗流量統計分析，以層積圖的形式展示在監控主界面。車載AC管理平臺將各單車用戶數據收集并通過Zabbix_Agentd上傳至Zabbix_Server端 。結合列車開行線路、車載W iFi在線用戶以及流量消耗，可作為綜合評價運行區段用戶活躍度重要參考指標。

3.2 數據推送模塊實現

Zabbix監控服務平臺通過對監控消息過濾后，一些可讀性不高的消息在被處理之后獲得良好的可讀性，因此，需要一個良好的通知機制將這些消息推送給運維人員[9-10]，Zabbix默認支持郵件告警功能，但存在被攔截的概率或郵件接收不及時甚至容易被忽視[11]；短信推送則需要調用信息網關，會產生一定的費用。綜合多方面因素，系統使用自定義腳本以釘釘APP作為媒介，推報平臺告警信息、運營統計信息、列車交路報表等信息，通過對關鍵監控數據配置故障告警觸發器并合理配置告警觸發的頻度與延遲閾值，達到列車運行異常即時上報，同時又避免頻繁誤報的現象。

4 監控系統應用

4.1 設備狀態監控

車載W iFi設備是鐵路動車組W iFi運營服務系統重要組成部分，其狀態好壞會直接影響鐵路動車組W iFi運營服務質量，因此，實時掌握車載W iFi設備運行狀態，是提高系統穩定，增強用戶體驗感的必然前提。Zabbix監控系統通過實時監測終端設備的心跳包(客戶端與服務器間的響應數據包)，根據其呼應頻率特性分析，判斷設備在線狀態。車載接入器（AP）作為W iFi運營服務系統中數量多，易被攻擊的設備，其狀態的好壞對整個系統穩定顯得至關重要，本監控系統設置30 s為一上報周期，對其狀態進行實時性監控。預設AP在線狀態值為1，不在線狀態值為0，車載控制器（AC）設定15 m in為一周期，對AP上報狀態結果進行分析判定，以單車廂分組（每單車廂固定配置2個AP），展示出周期內上報數據的最新值、最小值、平均值、最大值，根據圖形化狀態圖趨勢[12]，直觀獲取終端AP在線狀態，進而評估系統的穩定性。其狀態分析展示如圖5所示。

圖5 AP狀態監控圖

4.2 系統應用監控

通過對終端設備系統應用參數的采集，將實時數據進行圖形化展示，圖6展示了應用系統1 m in內的平均負載、內存占用的歷史記錄。隨著列車開行時間的推移，鐵路動車組W iFi運營服務系統接入用戶數累計增加，中間件（M YSQL）事務每秒查詢和回滾率隨之上升，通過對多系統參數指標的參考，用以整體性分析、評估系統運行的平穩性和健壯性。

圖6 設備系統參數監控圖

4.3 運營商網卡數據監控

通過使用腳本程序添加自定義監控參數，形成監控網卡數據的可視化界面。從圖7可以看出列車在不同行駛時間、行駛區段各運營商網卡信號強度的變化趨勢，圖8展示了旅客用戶在W iFi使用過程中帶寬的實時變化趨勢，圖7、圖8中都有出現數據急劇變化的區段，這與列車穿過隧道或車站，隧道或車站對運營商的信號有很大的屏蔽效應有直接關系，同時，信號強度以及帶寬上下的波動會受鐵路沿線運營商信號覆蓋率的影響。

5 結束語

基于Zabbix監控技術與數據可視化研究的基礎上，針對Zabbix分布式、可擴展性等特點，結合鐵路動車組W iFi運營服務系統運營數據建立監控環境，進行Zabbix監控系統的搭建和優化，利用其強大的應用程序接口（API）擴展能力，實現了動車組W iFi運營服務系統相關資源的整合。通過用戶定制，添加自定義監控項，完成了對動車組W iFi運營服務系統數據的可視化監控與管理，這些改進突破了傳統系統平臺的運維管理方式，整合了監控管理工具和通用集中監控系統的優勢，對保障鐵路動車組W iFi運營服務系統平穩運行具有重要意義。本監控系統全面應用以來，以監控代替檢查，實現了系統運維的數字化、信息化及自動化，不但節約了運維人力的投入，而且精準度高，預警性強，切實為鐵路動車組W iFi運營服務系統起到了保駕護航的作用，同時，該系統監控系統的建設及改進對類似大型企業級應用具有借鑒價值。

圖7 4G通信單元信號強度圖

圖8 網卡下行帶寬圖