基于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监控系统采用主动式上报模式对终端数据项进行采集，以减少监控系统服务端的请求压力。基于动车组W 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 网卡下行带宽图