铁路电子支付既有的应用监控是在电子支付平台投产初期设计实现的^[1]，采用Oracle数据库和Java语言开发，以交易日志为基础对不同支付方式的交易进行实时监控，监控数据存放于电子支付平台对账库中，监控内容和预警项目较单一。随着支付业务不断扩大，监控系统在数据采集、存储、计算压力等方面的不断增加，在监控预警、数据统计分析、运营维护（简称：运维）管理等方面的需求不断提升，既有监控系统已不能满足应用需求。为提高电子支付应用监控水平和对异常事件的应急处置处理能力，维护电子支付的安全稳定运行，本文设计并实现了以面向大数据和基于时间序列的数据处理、基于算法的业务分析等为关键技术的新一代铁路电子支付应用监控系统（简称：本文系统）。

1   系统设计

1.1   系统总体架构

本文系统总体架构主要分为4层，分别为采集层、汇聚层、存储层和应用层，各层的服务组件由Ansible管控中心统一配置管理。本文系统以交易日志、应用日志、操作系统日志等为基础，建立了一套高性能、高可靠性的数据传输体系，完成数据从生产业务端到大数据系统的传输。监控数据源既包括交易和业务产生的增量数据，也包括操作系统、应用服务、安全隔离等日志信息；本文系统既支持实时流式计算，也支持各类时间窗口的准实时批量计算，其总体架构如图1所示。

图  1  新一代铁路电子支付应用监控系统总体架构

下载: 全尺寸图片 幻灯片

1.1.1   采集层

采用后端Agent采集机制，在电子支付平台应用服务器上部署Agent指标采集，收集需要提取的日志信息和监控指标^[2]，主要包括应用日志、交易日志^[3]、支付安全隔离日志及应用服务、操作系统运行状态指标。所有Agent节点均通过Ansible管控中心实施统一运维管理，不但使操作维护更加直观，而且具备高可靠、可扩展等特点，有效降低了管理和运维成本。

1.1.2   汇聚层

汇聚层主要负责监控指标和应用日志的汇聚、转发与处理。支付应用日志、支付安全隔离日志、应用服务、操作系统运行状态等信息由Agent端把采集到数据发送到分布式消息队列Kafka，实现数据汇聚；Kafka支持队列分区、消息冗余与持久化，确保日志数据能够被高效可靠地转发与处理。交易日志的实时处理采用流计算服务Flink实现^[4]，Flink吞吐量高并且延迟低，能够支撑监控日志数据大批量实时处理；并且Flink支持复杂事件处理（CEP），能够实现重复支付分析、支付账户分析等复杂业务的告警规则。

1.1.3   存储层

存储层主要负责日志数据、指标数据、交易数据的存储与分析，该层采用了多种存储类别，包括分布式搜索和数据分析引擎（ES，Elasticsearch）、时序数据库（Clickhouse）^[5]、关系型数据库（PostgreSQL）、分布式文件存储（HDFS，Hadoop Distributed File System）。其中，ES负责应用日志、安全平台日志的存储、检索与分析^[6]；Clickhouse负责交易数据、主机和操作系统指标的存储、查询与分析； PostgreSQL存放监控系统的管理类和功能类数据，主要包括功能配置、用户管理、巡检记录、待办事件、知识库等数据信息；HDFS负责历史数据的存储和数据挖掘^[7]。

1.1.4   应用层

应用层以电子支付交易日志、应用日志、服务器运行数据、业务处理数据等为基础，形成集交易监控、基础环境监控、业务监控、预警告警、运维管理、运维处置为一体的监控和运维管理系统。

1.2   网络架构

本文系统网络部署如图2所示。

图  2  新一代铁路电子支付应用监控系统网络部署

下载: 全尺寸图片 幻灯片

本文系统主体建设在电子支付二中心的支付内网，全部监控数据均在二中心内网存储落地。应用日志、安全平台日志、服务器运行状态等监控数据将双中心的数据按照内网、外网进行汇聚，外网监控数据再通过电子支付内网与外网安全隔离专设的网络通道统一汇聚到内网。电子支付交易日志仅记录在支付内网，因此交易日志直接在内外汇聚即可。

1.2.1   支付外网

在电子支付一中心和二中心的外网应用服务器部署Agent数据采集器，全部Agent由外网Ansible进行统一配置和管理。外网Agent均与二中心支付外网Kafka集群互联，将应用运行状态、应用日志、安全平台日志等数据通过监控日志转发和接收服务汇聚至二中心支付内网。支付内网与外网在物理上隔离，两个网络之间的访问必须通过内网与外网安全隔离专设的网络通道。

1.2.2   支付内网

在电子支付一中心和二中心的内网应用服务器部署Agent数据采集器，全部Agent由内网Ansible进行统一配置和管理。内网Agent均与二中心支付内网Kafka集群互联，实现内网应用运行状态、应用日志、安全平台日志的数据汇聚。

2   系统功能

本文系统主要功能包括交易监控、系统环境监控、业务监控、监控和告警、运维管理、运维处置等主要功能，如图3所示。

图  3  新一代铁路电子支付应用监控系统主要功能

下载: 全尺寸图片 幻灯片

2.1   交易监控

交易监控主要按照不同业务，不同支付方式和不同支付机构等3个维度对实时交易情况进行展示和监控。交易可视化展示采用业界应用比较普遍的Grafana组件，其在时序分析及监控展示方面非常高效灵活。Grafana可以根据需要将电子支付交易监控和数据分析按照柱形图、曲线图、折线图、饼状图等不同方式展示；可以灵活配置监控数据统计和展示的时间范围；可以灵活扩展监控项，细化支付监控的颗粒度。

2.2   系统环境监控

在电子支付相关服务器中部署数据采集代理Telegraf，实时采集服务器CPU、内存、磁盘等操作系统信息和应用端口状态信息，并设置告警阈值，当超过阈值时进行系统告警和钉钉同步告警，从而实现对铁路电子支付平台基础环境资源的监控。

2.3   业务监控

本文系统基于电子支付的文件入库、支付对账、数据核算、退款处理等业务处理结果进行监控，对处理超时、处理结果报错、数据不同步、数据缺失、数据量异常等情况进行告警提示。

2.4   监控和告警

监控和告警主要功能包括建立监控指标，监控模板，监控项管理和告警记录等。设置监控指标是确定采集和监控的数据类别；监控模板是对一个或者多个监控指标进行配置，形成一个监控项，包括添加指标、设置监控指标阈值、设置统计周期、触发条件等，该功能支持对同一指标在不同时间段设置不同阈值进行监控告警，且通过设置的指标群支持告警收敛，支持通知指定联系人等；监控项管理是对监控项进行启动、停止、删除等统一管理；告警记录模块保留近3个月的全部告警记录，包括未处理告警、处理中告警及处理完成的告警，可根据告警类别、告警时间、告警关键字和告警状态等进行检索查询。

2.5   运维管理

运维管理主要功能包括排班管理、巡检管理、交接班管理、异常事件管理和待办事项等，用以规范和辅助日常运维管理相关工作。

2.6   运维处置

运维处置可以支持异常事件的排查分析和日常运维处置。日志检索使用ES（Elastic Search）进行日志管理与分析，支持按照不同业务、不同日志类型、不同应用集群等维度进行检索，设置常见的错误类型对日志进行扫描和关键字告警提示；数据浏览支持监控数据库在线统计查询；峰值查询按天对交易的分钟级峰值和秒级峰值进行查询；特征查询对支付账户近7天的付款笔数、退款笔数、关联支付IP、关联铁路12306互联网售票系统（简称：12306）账户等交易特征进行统计查询。

3   关键技术

3.1   基于双活架构、混合云的高安全及高可靠技术

本文系统总体架构以电子支付平台双中心双活架构为基础，数据采集、传输、管理等服务基于支付平台的VMware和铁信云混合部署，服务通过多中心和异构平台实现其高可用。本文系统通过虚拟化平台结合统一的自动化工具进行双中心监控数据的配置管理、应用部署、任务分配等，实现数据跨中心、跨平台的汇聚和服务管理，满足系统功能快速上线和平稳运维，最大限度地保障新一代电子支付监控服务运行稳定。

3.2   面向大数据的数据处理

本文系统面向铁路电子支付平台海量的交易数据、业务数据和日志数据，采用多项大数据关键技术，数据处理流程如图4所示。服务器上的监控源，包括系统日志、系统指标、应用日志、业务指标等，由Agent上的各类插件自动匹配并采集数据，将采集到的交易日志和应用日志数据汇聚到分布式消息队列Kafka，交易日志数据通过流计算服务Flink以事件型驱动方式触发相关计算，快速对数据的变化做出响应，实现支付交易、业务的实时分析和监控预警。Flink处理后数据存储在Clickhouse中，用于可视化监控的绘制和分析；应用日志数据存储到ES中，用于日志的扫描、检索和告警；经过一段时间后，近期数据存储经过离线分析算后存储到分布式文件系统，并依此形成大数据平台用于历史数据的检索和分析。

图  4  新一代铁路电子支付应用监控系统数据处理流程示意

下载: 全尺寸图片 幻灯片

3.3   基于时间序列的数据处理

电子支付平台操作系统、业务等监控数据均是基于时间的一系列的数据，即时序数据，本文系统采用Clickhouse存储监控数据，将海量的电子支付数据根据时间戳排序存储，写入时自动按时间分块，有效地减少了输入/输出所需要的额外资源；同时，时间序列的数值型数据的压缩率较高，大幅降低了监控系统的存储成本。Clickhouse采用分布式存储架构，利用分布式计算和数据分片模式，在原监控系统的基础上大幅提高了计算效率。

3.4   基于算法的业务分析技术

本文系统采用XGBoost算法对部分支付业务数据进行统计分析，进而支持业务监控。如用户支付账号分析功能，该功能以客运电子支付的支付账号标识为基础，对支付机构、支付方式、支付时间、支付金额、支付频次、退票频率、支付IP、支付的内容分发网络（CDN，Content Delivery Network）节点、退票时长等不同特征进行分析和查询。基于支付历史数据，通过在Python平台下使用XGBoost算法实现对特征明显的电子支付交易数据进行特征处理和模型训练，再用训练好的模型对所有支付数据进行预测，得出支付行为风险分析结果和特征结果集^[8]，让分析人员对于当前支付交易风险度有一定的预判，从而可以支持进一步的风险对抗决策，为业务决策部门提供了一个有效的风险分析的模型。

4   应用场景

4.1   交易综合监控

铁路电子支付目前的业务类型主要为客运业务和货运业务，并且已经引入工商银行、农业银行、中国银行、建设银行、招商银行、邮储银行、银联、支付宝和微信支付等13家金融机构，支持互联网、手机、扫码、POS刷卡、TVM自助、中铁银通卡刷卡进/出站等多种支付方式。本文系统的交易监控主要按照不同业务、不同支付方式和不同支付机构等3个维度对实时交易情况进行展示和监控，同时，对当日交易转接数据、总体付退款请求数、交易量、交易金额等进行实时统计和展示。

4.2   电子支付全景监控

综合电子支付基础环境监控、应用监控、业务监控等形成电子支付全景监控。全景监控以电子支付部署拓扑图的形势实时监控展示电子支付CDN、数据库、网络出口等重要数据，同时，后台同步扫描安全隔离、负载、应用服务、当前交易等运行情况信息。任何环节的异常均通过弹窗形势反馈到全景监控页面，从而实现对电子支付总体运行情况的实时掌握，确保发生异常时能够迅速准确定位支付异常环节和异常原因。

4.3   重复支付分析

当支付环节出现频繁访问或响应超时，会发生同一笔订单重复支付的情况，对电子支付当日或近期的交易数据进行分析，统计筛选出重复交易的明细，从重复支付交易的交易间隔、支付机构、业务类别、支付方式、所属中心等维度对重复支付交易进行分析，并以可视化形式展示分析结果。业务人员可根据统计结果掌握重复支付总体情况，初步判断重复支付的原因，便于业务部门进一步决策。

5   结束语

本文系统的实施显著加强了铁路电子支付应用监控和运维处置能力。本文系统每天从电子支付约120 GB的应用日志中采集和提取日志信息，记录并存储监控数据1.2亿条，每分钟实时处理电子支付交易数据约40万条，平均查询速度15 ms，对铁路客货运电子支付交易及业务办理均进行了全面监控和有效预警，具备应对春运及节假日高峰期客货运业务量大幅增长的处理能力；本文系统预警设置和监控展示灵活便捷，支持指定交易的精准分析，有效地提高了技术和业务人员运维处置能力和日常工作效率。

本文对电子支付平台既有监控系统进行了全面优化和升级，未来将以大数据、云计算，甚至人工智能技术为依托，在兼顾数据加密、访问控制等数据安全的前提下，向更加智能化、自动化的方向发展，全面提高监控的效率和准确性，有力保障铁路客货运电子支付服务。