铁路数据中心智能运维管理系统初步研究

赵 天，刘 宇，何欣玲，黄思炜

（中国铁路信息科技集团有限公司，北京 100844）

随着铁路信息化的不断发展，铁路数据中心运维工作日趋复杂。当前，云计算已逐渐成为铁路信息系统的主流技术架构，铁路数据中心云化进程不断加快，其运行与维护（简称：运维）环境的复杂化和异构特征越发突出，面对着更加多样化的业务需求，铁路数据中心的日常运维工作不得不投入更多的人力和时间，成本越来越高。

中国铁路信息科技集团有限公司发布的《十四五战略发展规划》中指出，铁路数据中心将形成两地三中心架构，构建统一运维管理，形成弹性分配资源的技术与服务管理体系[1]。两地三中心即同城双活中心、主数据中心和异地数据中心，且远期铁路数据中心将朝着多地多中心方向发展。

为应对目前铁路数据中心运维工作面对的压力和挑战，适应铁路信息化未来发展要求，铁路数据中心需要采用更为高效的运维模式，实现异地多中心的统一运维管理，能够及时、准确地掌控各铁路数据中心资源及业务应用系统的运行情况，实现铁路数据中心运维人力资源的统一调配，保障铁路信息系统安全、稳定地持续运行。

近年来，智能运维在信息技术领域受到广泛关注，随着大数据分析、云应用性能管理（APM，Application Performance Management）、智能异常检测、机器学习等技术的兴起和逐渐成熟，数据中心运维逐渐转向数字化和智能化[2]，由传统模式向智能运维管理（AIOps，Artificial Intelligence for IT Operations）演进。

本文结合铁路数据中心云化趋势和多地多中心发展要求，为实现全路铁路数据中心的集中运维管理，提出铁路数据中心智能运维管理系统方案，重点对运维数据采集、运维监控指标体系及运维数据存储展开研究。

1 铁路数据中心智能运维目标

（1）实现全路铁路数据中心集中运维管理：建立铁路运维管理中心，可采集和汇总异地多铁路数据中心的运维数据（日志、监控信息、应用信息等），通过大数据处理和智能分析，全面掌控各铁路数据中心整体运行状况，包括网络设备、物理服务器、存储设备、虚拟服务器、操作系统、数据库、应用系统等运行状况。

（2）统一铁路数据中心运维管理服务水平：规范各类监控对象的监控数据采集，建立标准的运维管理指标体系，以统一各铁路数据中心运维管理服务水平。

（3）提高铁路数据中心运维效率：通过海量运维数据有效采集、存储、自动处理和智能分析，提供异常检测、故障分析、运维辅助决策等运维应用，支持阶梯式运维团队协同工作，确保铁路数据中心安全稳定运行和资源配置持续优化。

2 铁路数据中心智能运维管理系统方案

2.1 总体架构

构建铁路数据中心智能运维管理系统，实现对多个异地铁路数据中心的统一运维管理，兼容跨区域复杂网络，从各铁路数据中心采集各类监控对象的运维数据，并汇集到运维管理中心。

铁路数据中心运维管理系统包括数据采集层、数据存储层和业务服务层，总体架构如图1 所示。

图1 铁路数据中心运维管理系统总体架构示意

（1）监控对象层：涉及各铁路数据中心的各类监控对象实体，包括供电、空调、温湿度传感器、UPS 等基础环境设施，PC 服务器、存储、以及路由器、交换机等IT 硬件设备，云平台服务、虚拟机、操作系统、数据库、中间件等系统软件，以及各业务应用系统等。

（2）数据采集层：包括代理和采集控制平台；代理从铁路数据中心收集各类监控对象的运行状态数据（即原始的运维监控数据），按照统一口径进行统计分析，生成运维监控指标数据，与原始的运维监控数据一起上传给采集控制平台；采集控制平台负责接收代理上传的数据，同时对代理进行调度管理。

（3）数据存储层：存储从监控对象采集得到的原始运维数据，以及经分析处理后的运维监控指标数据。

（4）业务服务层：完成运维指标数据的关联分析和智能分析，为运维管理中心阶梯式运维团队（包括运维管理人员及一线、二线、三线的运维人员）提供运维数据可视化展示、统计报表、自动告警通知，为异常检测、故障分析、运维辅助决策等运维业务提供强有力支持，建立起7x24 h 的应急响应机制。

2.2 数据采集层

数据采集层主要由部署在铁路数据中心一侧的代理和运维管理中心一侧的采集控制平台构成。

（1）代理是部署在各个铁路数据中心不同网络区域内的各类专用程序，可采用拉和推2 种的工作模式，收集各类监控对象的运维数据。代理程序还会对运维数据进行预处理[3]，剔除重复数据、空值数据和异常数据等，然后按照统一口径进行统计分析，生成运维监控指标数据，将原始的运维数据与监控指标数据一起上传至采集控制平台。

（2）采集控制平台是铁路数据中心运维管理系统的核心，负责接收代理上传的数据，并对代理进行调度管理，控制代理采集和上报数据的周期；设置有插件库，可按需向代理下发插件，完成代理程序的升级更新。采集控制平台主要由数据服务网关、数据缓存队列和大数据处理组件3 个组件来完成。

数据服务网关由LVS+Keepalive+Nginx 组成；其中，LVS 负责接入代理数据流，可提供4 层高效负载均衡；Keepalive 保障LVS 具有高可用性，避免LVS 出现单点故障；Nginx 负责将数据均衡传输至数据缓存队列，可支持7 层应用数据传输负载均衡。

数据缓存队列采用Kafka 实现，将接收的运维监控数据缓存起来，并通知采集控制平台尽快将其存入数据库。Kafka 是一个分布式、多分区、多订阅者模式的日志和消息系统，支持冗余备份，具有处理速度快、高吞吐、支持分布式部署等特点。

大数据处理组件Spark 用于海量运维监控数据的大数据处理。通过流式计算，采用ETL 技术对运维监控指标数据进行清理、过滤、转换定义，实现数据标准化、规范化。Spark 可以采用图形化和表格的形式进行快捷配置，对运维监控指标数据进行解析、提取、清洗、替换、分类、加注标签、添加信息项、归并等处理，并将海量运维数据快速存入数据库中。

2.3 数据存储层

在云计算环境下，铁路数据中心每年会产生高达数以百TB 的运维数据，传统关系型数据库难以满足其存储要求。运维监控数据存储需要考虑海量数据的写入性能[4]、查询效率、按时聚合等数据处理要求[5]；此外，鉴于不同类型监控对象间关联关系是数据分析的关键[6]，数据存储还应为关联分析提供高效的数据访问支持。

数据存储层使用ElasticSearch、 MongoDB、MySQL、Redis 等多种类型的数据库，满足异构的海量原始运维数据的不同存储要求；采用集群部署方式，满足数据量快速增加时横向扩容的需求。

2.4 业务服务层

提供统一运维门户，采用微服务技术架构，实现数据分析、报表和可视化功能模块的组件化和服务化，每个服务可独立开发、部署和发布，具有较好的可扩展性，便于系统维护与升级。

3 运维数据采集需求及运维管理指标体系

3.1 铁路数据中心运维数据采集需求

在云计算架构下，铁路数据中心的资源种类更多，运维监控对象构成更为复杂。铁路数据中心运维监控对象可划分为基础环境设施、IT 硬件设备、系统软件、业务应用系统4 大类。基础环境设施包括供电、空调、UPS 等；IT 硬件设备包括PC 服务器、存储、以及路由器、交换机、防火墙等；系统软件包括云平台服务、操作系统、数据库、中间件、虚拟服务器等；业务应用系统是部署在铁路数据中心的各类铁路信息系统。

为此，需要采集的铁路数据中心运维数据主要包括以下4 类：

（1）基础环境设施数据：包括机房温度、湿度、供电、红外等机房动环数据。

（2）IT 硬件设备数据：支撑整个业务、应用系统的基础设施运行环境产生的数据，包含对服务器、网络设备、存储设备的运行日志数据，指示灯报警数据等。

（3）系统软件数据：包括操作系统、中间件、数据库、大数据组件的运行状态数据，系统软件日志数据。

（4）业务应用系统数据：包括应用系统的整体性能指标，系统运行状态、响应时间、系统运行日志等；还包括应用系统中各个具体业务应用的性能指标，如当前请求的响应时间、请求量、运行状态等。

这些数据能够表征铁路数据中心的整体运行状况，运维人员可利用这些数据，了解系统运行健康状态和资源占用情况，分析和判断业务应用系统是否需要扩容或缩容。

3.2 运维数据分类

数据中心智能运维管理系统应能对每一种监控对象采集动作抽象，实现基础环境设施、IT 硬件设备、系统软件、业务应用系统的统一管理。运维指标数据可分为4 类：配置数据、监测数据、日志数据和事件数据。

（1）配置数据：描述资源对象的配置属性，包含资源对象本身的属性，以及资源对象间关联关系，这类数据仅在资源对象的属性或资源对象间关联关系发生变更时才有变化。

（2）监控数据：主要是各类资源对象运行过程中产生时序指标数据，随着时间积累很快，例如：CPU、内存、磁盘、网络状态、流量、响应时间等，主要用于反映业务和系统的运行情况及状态；这类指标数据必须采用相同的统计口径，具有可比性。

（3）日志数据：日志数据一般是文本类型数据，主要包括资源对象的运行日志和业务应用的运行日志；可通过关键字或正则匹配，在日志数据中发现关键信息。

（4）事件数据：是运维过程中，由监控数据或日志数据产生的一类特殊数据，用来记录发生的特定事件的相关信息，例如报警、异常、上线变更、任务调度等事件；事件分为一般事件和告警事件。

其中，监控数据量最大，主要记录每时每刻主机、业务服务请求的性能指标，这类指标的样本抽样数据的采集需要做到秒级。日志数据占用的存储空间最多。事件数据主要是各类业务应用系统推送给监控系统的邮件，数据中心基础设施管理（DCIM，Data Center Infrastructure Management）系统监测的温湿度、报警指示灯等消息事件等，这类数据需要由监控系统进行分析，并生成标准事件格式；告警是一种特殊的事件，告警数据包括监控系统生成的告警信息，以及来自于业务应用系统的告警信息。

3.3 铁路数据中心运维管理指标体系

基于上述运维数据，构建铁路数据中心运维管理指标体系，如表1 所示。

表1 铁路数据中心运维管理指标体系

各指标数据项由指标元数据定义，如表2 所示。

表2 铁路数据中心运维指标元数据定义

铁路数据中心资源种类繁多，需要根据不同种类资源定义其配置数据的数据模型，且配置数据的数据模型还会因资源属性变更而发生变化。而监控数据、日志数据、事件数据这3 类运维指标数据，则可以定义相对固定的数据模型。表3 描述5 种数据模型：配置模型、指标模型、日志模型、事件模型、告警模型。

表3 运维指标数据的数据模型（数据定义）

4 运维监控数据采集与存储

4.1 运维监控数据采集

在云计算和异地多数据中心的架构下，运维监控对象种类及数量急剧增加，涉及硬件层、云平台服务层及应用系统层，运维数据采集方式存在诸多不同。针对不同类别监控对象，可灵活采用多种数据采集方式。

（1）基础环境设施：对于机房空调、供水、供电、防火设备等设备设施，通过巡检机器人[7]获得动环报警器、设备指示灯的声光电告警事件信息，通过嵌入式传感器（如温湿度传感器）等获取环境信息。

（2）IT 硬件设备：对于云平台的主控节点、计算节点、网络节点等物理服务器和存储设备，一般通过IPMI 协议获取机柜、机箱或服务器的报警事件数据，通过巡检机器人检查硬件报警指示灯信息，通过SNMP 协议主动获得网络设备性能指标数据；对于支持RESTful 协议的IT 硬件设备，可通过RESTful 主动采集其CPU、内存等性能数据。

（3）系统软件：对于操作系统以及在其上运行的KVM、Libvirt、QEMU 等基础系统软件，通常通过远程连接（RPC）获取性能指标和运行日志；对于Keystone、Nova、Glance 等云服务，通过RESTful的方式获得其监控数据；对于虚拟机，可通过内部虚拟机守护代理（QGA，QEMU Guest Agent）程序获得其性能指标和日志数据。

（4）业务应用系统：可通过Syslog 获得业务应用系统的运行日志，通过HTTP/HTTPS 协议获得其服务响应状态和响应时间等性能指标。

代理程序通过本机或远程等方式执行运维数据采集任务，并可采用分布式级联的形式，对数据逐级汇聚后传输至采集控制平台。针对不同的监控对象，代理程序定制了不同的采控插件，拥有面向监控对象的采控能力服务化封装，以脚本或插件方式按需扩展，实现大规模节点数据采集任务秒级调度，以及跨数据中心、多网络环境下运维数据采集的统一控制。

4.2 运维监控数据存储

所采集的运维监控数据经过预处理后，先写入消息队列中，采集控制平台调度流式任务，从消息队列件里读取数据，根据数据的用途和访问频次进行分类存储[8]。根据重要程度/时间等要素，对运维监控数据进行分类，不同类别数据采用不同的数据生命周期管理策略，实现数据的快速查询汇聚，满足多种数据使用需求。

4.2.1 即时访问的热数据

对于时序指标数据、告警数据等查询类数据，可采用 ElasticSearch 进行存储；ElasticSearch 具有列数据库的水平扩展能力，支持吞吐量线性扩展，特别适用于保存与时间有关的指标数据。

另外，在指标阈值分析和仪表盘操作时，均需要高频访问最近24 h 的热数据。使用Redis 内存数据库，将这类热数据存储在内存，在出现高并发请求时，能大幅度减少磁盘IO，提高数据处理响应速度，保证高效的数据查询检索和分析处理。

4.2.2 无需即时访问的温数据

资源配置数据和资源对象间关联关系数据一般不需要即时访问，但也会经常被使用到，对于这类温数据可以使用关系型数据库进行存储。

关系型数据库能够保证数据强一致性，适用于存储系统配置信息、功能策略、管理参数、管理任务等数据量不大的关键数据，并且还可采用反范式设计来平衡数据库存取效率和事务完整性。

资源对象间关联关系数据涉及到的大量资源实体之间错综复杂的关系，可采用关系型数据库MySQL 进行存储。MySQL 提供图形数据存储模式，能非常自然地映射资源间关系，可支持图形数据高效检索和拓扑关系分析。此外，MySQL 也具备事务一致性和一定水平扩展能力，也适于应用在资源配置数据分析方面。

4.2.3 长期存档的冷数据

对于配置管理信息、运维日志等使用频次较低，但又需要长期存储的冷数据，采用文档型数据库MongoDB[9]进行存储。

MongoDB 在海量数据存储方面具备明显优势[10]，存储模式灵活自由，检索能力强，读写性能均衡，可支持主备、分片式集群，在性能和扩展能力也超过关系型SQL 数据库。

5 典型应用场景

目前，主要面向异常检测、故障分析、运维辅助决策3 类运维业务，进行了初步应用开发。

5.1 异常检测

为实现精准的监控指标异常检测，除了常规的静态阈值检测外，还使用动态阈值、周期性分析等技术。相比传统的静态阈值检测，动态阈值考虑了监控数据的周期性变化、历史趋势变化以及波动幅度变化规律，通过对此对象的监控数据走势进行数字建模，可计算得到监控值在将来一段时间里的合理范围。

动态阈值技术主要有线性回归、时间序列分解、长短期记忆网络网络（LSTM，Long Short-Term Memory）。时间序列分解的计算速度最快，LSTM具有理论上最优分析精度，线性回归处于中间水平。考虑到数据中心监控指标异常检测计算量极大，采用时间序列分解进行动态阈值预测，效果如图2 所示。

图2 基于动态阈值的异常检测效果图示例

5.2 故障分析

当铁路数据中心出现故障时，若故障排查完全由运维人员的分析判断，运维人员需要登录多台设备，逐一检查监控对象的各项指标，依据经验判断故障，故障排查过程耗时费力。

为此，汇总历史异常数据，挖掘和分析与各类问题现象相关的运维监控数据项，确定相关性较高的数据项范围，以此确定故障排查页面所需要展示的数据项。通过对大量运维监控数据的关联分析，故障分析功能可为运维人员提供与故障诊断相关的重点关注数据，并可自动分析可能的故障原因[11]，便于运维人员确定问题类型，快速定位问题，帮助其提高工作效率。图3 为单机故障排查页面，集中显示CPU、内存、磁盘等资源的消耗变化情况、设备近期工作强度变化情况、以及对应集群和存储等硬件环境的工作状况。依据该页面提供的综合信息，运维人员可快速判断故障产生的位置和时间范围，无需逐一查看各项指标。

图3 单机故障排查页面

5.3 运维辅助决策

通过统计和预测各个铁路数据中心资源的使用情况，为运维人员提供资源负载清单，并对资源消耗情况进行预测，便于运维人员全面掌握每个铁路数据中心各类资源的使用状况（闲置、高负荷、使用率等）和趋势，及时制定性能调优方案，进行合理调度管理；并根据各类资源的预计耗尽时间，提前进行资源扩容准备，避免因资源耗尽而宕机的风险。对于铁路数据中心资源消耗预测，也可使用时间序列预测方法，对未来资源耗尽的时间进行预测，如图4 所示。

图4 运维辅助决策支持应用示例

6 结束语

结合铁路数据中心云化趋势和多地多中心发展要求，本文提出铁路数据中心智能运维管理系统方案。铁路数据中心智能运维管理系统划分为监控对象层、数据采集层、数据存储层和业务服务层，兼容跨区域复杂网络环境，从各个铁路数据中心采集运维数据，汇集到运维管理中心，实现对异地多数据中心的统一运维管理。在全面分析铁路数据中心运维数据采集需求的基础上，建立铁路数据中心运维管理指标体系，深入探讨运维监控数据采集与存储技术，为铁路数据中心智能运维管理系统的开发奠定了基础；此外，还初步开发了异常检测、故障分析、运维辅助决策典型运维业务应用。

在实现铁路数据中心运维监控数据采集与存储的基础上，下一步将聚焦于智能分析算法模型的研究，并基于此推进运维业务应用的迭代开发，提升铁路数据中心运维业务的自动化、智能化水平，促进铁路数据中心运维业务模式创新，为形成弹性分配资源的技术与服务管理体系提供强有力支持。