证券集中交易系统是券商的核心业务系统，保障该系统稳定运行是券商交易业务可持续发展的绝对基础和必要条件。兴业证券在推进基础设施“数智化”转型的过程中，针对传统Agent代理和日志解析监控集中交易系统的不足，选择采用网络流量旁路业务关联分析的方式，对集中交易系统业务流量进行高性能采集、重组、关联分析，实现了交易过程全链路端到端的可视化管理，利用网络报文回溯分析技术及时还原故障现场，帮助运维人员快速定位问题根因，提升排障效率，解决了困扰多年的故障重现难题。
一、引言
证券集中交易系统是券商的核心业务系统，保障该系统稳定运行是券商交易业务可持续发展的绝对基础和必要条件。然而在系统运维过程中，由于系统架构复杂，运维人员使用传统运维工具排查故障效率低，无法还原故障现场，难以快速定位故障根因。为此，兴业证券在“数字基建”旅程中不断探索，最终选择基于网络流量的旁路业务关联分析的方式，在集团两地三中心部署旁路业务监控系统，实现集中交易系统的交易过程全链路端到端的监控管理，帮助运维人员精准高效定位故障，大幅提升排障效率，尤其解决了困扰多年的故障发生第一时间现场重现的难题。
二、监控方式选择
对于集中交易系统的运行监控，传统的Agent监控和日志监控方式均存在不足，近年来一种基于网络流量旁路监控业务系统的全新方式逐渐成为主流，以下就这三种方式展开分析。（一）Agent监控
Agent监控是在被监控系统的组件内安装Agent软件，即代理软件，实现对数据的采集和管理。但该方式要植入系统组件内，对系统具有侵入性，且需随着系统的版本迭代而不断更新，因此，对稳定性和安全性有极高要求的券商核心交易系统，不宜采用Agent方式进行业务监控。（二）日志监控
日志监控是通过读取IT设备的系统日志以及应用系统预先定义输出的日志文件进行解析来实现业务系统监控，但存在以下三点不足：（1）因日志依赖于厂商预定义难以及时满足需求的个性化定义；（2）因性能损耗影响应用系统运行性能；（3）因网络传输毫秒级时延无法满足高精度业务监控的要求。（三）网络流量旁路监控
网络流量监控是通过关联分析被监控系统之间网络通信的数据，实现应用系统性能、业务活动、网络状态等多方面信息的监控。全球最具权威的IT研究与顾问咨询公司Gartner已将网络流量方式列入主流的应用监控方式，体现了网络数据对应用系统监控的重要性，其优势主要表现为以下三个方面：
（1）监控零风险。网络流量旁路方式与集中交易系统不进行任何交互，不消耗交易系统资源，不影响业务系统的正常运行，是一种零风险监控方式。
（2）时间精度高。网络数据的时间戳由TAP交换机捕获并进行标记，网络镜像数据时延取决于交换机处理数据包的耗时，以10G交换机为例，处理64字节长度的数据包帧，理论串行化时延为51.2纳秒，叠加交换机镜像的处理时延，时间精度可控制在微秒级。
（3）网络数据可回溯。网络数据可呈现业务活动、网络状态等多方面信息，因此在故障发生时，能够实时记录故障现场，为运维人员定位问题提供真实原始的业务数据。
综上，鉴于Agent和日志方式在集中交易系统监控运用的不足，兴业证券采用网络流量旁路监控的方式对集中交易系统的业务进行监控。
三、系统建设与实践
（一）系统建设
1、系统逻辑架构图
旁路业务监控系统逻辑架构是由采集层、网络报文解析层、监控与接口层、数据分析层组成（图3-1）。
图3-1系统逻辑架构图
采集层主要负责采集物理环境、虚拟化环境的网络报文，并将网络报文传输至网络报文解析层。
解析层主要包含网络报文重组、解码、关联、数据预处理等，实现报文解码与关联后，输出可量化、可读的文本记录。
监控与接口层主要用于前台呈现与交互操作，提供告警、指标趋势分析、交易明细追踪、报表等功能，同时提供对外接口与第三方平台对接。
数据分析层主要实现各种创新运维与运营场景，通过钻取平台指标和维度数据，自定义视图分析，获得分支机构监控、领导驾驶舱、网络应用时延分析等。
综上，旁路的网络数据包经过“采集层”收集，“解析层”关联分析输出可读文本，再通过“监控与接口层”展示监控指标和运维报表，最后将多维度指标传输到“数据分析层”，为各种运维与运营场景提供数据支持。
在旁路业务监控系统的建设过程中，“采集层”和“解析层”是兴业证券数字基建网络数智化转型的体现，下文着重就这两层的技术选型和实现进行阐述。2、高性能网络流量处理技术的选型
采集层应满足交易系统开盘阶段爆发性增长的交易量，因此，采集层需具备高吞吐量处理能力，目前业内采用汇聚分流器方案，配置专用网络处理器（ASIC）。我司经流量压测，选用某品牌TAP交换机作为网络流量采集器。
网络报文由采集层发送至网络报文解析层的数据采集接口（图3-1），此接口程序运行在Linux系统上，由于Linux系统I/O通信无法支撑高流量负载下的数据接收，需要进行优化，目前主流高性能网络流量处理技术主要有：
（1）零拷贝技术，通过交换内核各层和内核到用户空间的内存地址来代替内存的数据拷贝，可提升高载荷数据包接收性能，然而对于小数据包效果不明显。
（2）PFRING技术，该技术核心思路是将底层报文拷贝到PF_RING环形队列，用户空间可直接访问在内核空间和用户空间所映射的环形队列空间，然而存在超大流量处理时，CPU单核占用率较高的问题。
（3）DPDK技术，Intel公司发布的数据平面开发套件，对于大量数据包转发具有显著的性能提升。核心思路是UIO（Userspace I/O）机制，采用零拷贝方式，通过DMA将网卡数据拷贝到接收缓存，通过MMAP映射到用户空间，使用户直接访问接收缓存（图3-2）。同时采用PMD（PollMode Driver）主动轮询方式，用户空间的应用程序快速收发数据包，减少CPU频繁中断、切换上下文带来的消耗。
图3-2 数据流向方向队列拆分
综上，对于上述高吞吐量处理的三种技术方案，其中DPDK技术拥有强大的社区支持和完善的协议类型适配。因此“网络报文解析层”的数据采集接口选择DPDK技术来解决高性能网络流量处理的瓶颈。3、网络报文重组和关联
“网络报文解析层”主要实现网络报文重组、网络报文关联。网络报文重组是针对网络通信过程中存在大量IP分片、应用层拆包的情况进行报文重组还原；网络报文关联是构建业务关联模型，将交易双方的多个会话进行有序的关联。以下就网络报文重组和关联的实现分别进行阐述。
（1）网络报文重组
为实现网络报文的重组，可分为两个步骤：
步骤1：识别网络报文拆分是IP层分片还是应用层报文拆分。IP层分片是由于网络报文长度超出网络设备MTU而触发产生，应用层报文拆分主要由应用程序根据业务逻辑和通信效率所定义的规则触发产生。
步骤2：针对上述两种拆分情况，分别进行报文的重组。IP分片重组主要依赖报文IP头部的关键标志位进行重组。应用报文重组主要依赖应用协议的关键标志位进行重组，通常需要对应用报文消息头和消息体进行检测，识别起始位和结束位（参见表3-1）。
表3-1 应用层报文重组标志位
以集中交易系统总线AR节点通信网络报文为例（图3-3），该应用层字节流呈现消息头和消息体结构，其中，应用报文消息头以16进制字节流“0x01 0x31 0x14”作为起始位，直到“0x31 0x3d”结束。应用报文消息体以“0x31 0x3d”起始，以“0x3d”的方式不断延伸，每个字段均以“0x00”作为间隔，结束也以“0x00”作为结束标志。
图3-3 总线AR通信报文
通过上述应用报文的分析，进行应用重组过程可分两个步骤：
步骤1：当IP分片重组过程处于第1到第N-1个IP分片时（假设N个分片），持续读取下一个分片，直到第N个分片完成重组。
步骤2：IP分片完成重组后，进入应用重组过程，若应用层字节流末位不是“0x00”，可判定应用层已发生业务数据拆分，并在UDP通信会话中读取下一个报文，持续检查结束标识位为“0x00”结束，完成应用重组过程。
综上，遵循协议层从下而上的分析思路实现网络报文重组，先识别IP分片，再识别应用报文拆分，并分别对其进行重组，达到还原完整网络报文的目的。
（1）网络报文关联
网络报文关联是指将交易双方的多个会话进行有序的关联。针对业务模型，可以总结以下三种关联模型。
模型1：同步会话模式。在同一个TCP/UDP会话的业务请求与应答（图3-4），可基于TCP/UDP会话五元组哈希值进行关联。
图3-4 同步会话模式
模型2：异步会话模式。分布在两个不同TCP/UDP会话的业务请求与应答（图3-5），可基于上层业务信息，比如流水号、用户号等，实现异步会话关联。
图3-5 异步会话模式
模型3：异步双向会话模式。分布在两个不同TCP/UDP会话的业务请求与应答（图3-6）。可结合“异步会话模式”关联方式，并按照业务方向进行有序关联。
图3-6 异步双向会话模式
以交易系统委托报盘为例，该场景为提升业务性能采用主动争抢式负载均衡技术，该技术逻辑以A服务作为核心支撑，以队列形式进行数据流的快速流转。
图3-7逻辑图
上述业务场景是同步会话模式与异步会话模式关联的应用（图3-8），第一步，序号1和2通过同步TCP/UDP属性字段关联；第二步，序号2和9通过异步业务字段“任务号”关联；第三步，序号9和10通过同步TCP/UDP属性字段关联，最终实现序号1- 2- 9- 10共四次交互的闭环关联。
图3-8闭环关联
综上，有序结合三种模式进行应用，可以实现对交易系统应用报文关联，形成单笔交易的闭环。同时，利用已完成关联的请求应用报文时间戳和应答应用报文时间戳两者的差值，计算得出可反映系统交易性能的处理耗时，为业务性能分析指标提供可靠数据支撑。4、系统部署拓扑图
旁路业务监控系统采用分布式部署方案，部署在集团两地三中心，系统主要由流量采集器（TAP交换机）和业务监控节点组成（图3-9）。
图3-9 系统网络部署图
流量采集器对集中交易系统主机的镜像流量精细化处理，减少冗余数据报文，提升业务监控节点处理效率。
业务监控节点采用主从分布模式，部署在多个数据中心。为减少主从监控节点的带宽消耗，仅当管理员进行数据分析时通过RESTAPI通信，主监控管理节点统一管理多个数据中心从监控节点，实现集中交易系统旁路业务监控的目标。（二）应用实践
旁路业务监控系统主要用于对集中交易系统的监控，与交易系统自身的监控相互补充，共同支撑集中交易系统的运维保障工作。在某次集中交易系统应急演练过程中，交易自身监控发现融资融券业务异常，应用耗时显著高于预设阈值触发告警，运维人员收到告警后立即进行排查，由于交易自身监控无法记录现场事件，不能满足运维人员全量回溯分析需求，运维人员采用旁路业务监控系统进一步进行排查分析，主要通过查询并分析“关键KPI指标”、“多维钻取分析”实现了故障定位，提高了故障排查的效率。1、关键KPI指标
旁路业务监控系统定义了四个关键KPI指标，分别是“交易量（系统负载）”、“响应时间（用户体验）”、“响应率（系统健康度）”、“成功率（业务健康度）”，这四个指标是结合谷歌的4个黄金指标经验总结来制定，即“延迟”、“通讯量”、“错误”、“饱和度”，可以在服务级别衡量终端用户体验、服务中断、业务影响等层面的问题。
在本次应急演练中，融资融券业务的应用耗时异常，通过查询相关KPI指标：“响应时间”。通过查询异常发生及之前的“响应时间”，我们发现，异常发生前的响应时间很稳定，低于10ms；异常发生时响应时间出现了明显的波动，最大时接近20ms（图3-10）。
图3-10 响应时间异常
同时，我们查看异常发生时的交易量（如图3-11），发现异常发生时的交易量没有明显变化，与异常发生前基本保持同一水平。因此，我们可以初步排除响应耗时上升是由于交易量上升导致。
图3-11 交易量趋势图
为了进一步分析异常应用耗时的详细情况，我们需要通过“多维钻取分析”来实现故障定位。2、多维钻取分析
在确定异常KPI指标的基础上，需要对响应时间做进一步的钻取分析，找出耗时异常的相关交易。对于融资融券业务，我们从以下三个维度进行分析：
（1）交易类型维度。通过功能号参数来定义交易类型，对主要的功能号，如委托、撤单、查询等交易类型，进行重点排查。
（2）交易渠道维度。针对不同的交易渠道，如网上交易、手机委托、柜台委托等，分别统计各渠道的关键指标，区分正常和异常的渠道。
（3）客户号追踪。定位系统异常影响的客户。
首先，查询第一维度：交易类型维度（图3-12）。通过钻取发现，“委托交易”类型（功能号335002）在异常发生时间点的平均响应时间达到2000 ms以上，而其他交易类型的响应时间属正常范围，因此可以判定耗时异常主要因功能号335002的委托交易引起。
图3-12 交易类型维度图
其次，查询第二维度，交易渠道维度（参见图3-13），某渠道的响应时间达到6000 ms以上，是导致“委托交易”功能号响应时间过高的原因。由于该渠道委托交易量很大，导致交易耗时指标严重超过正常水平。
图3-13 交易渠道维度图
通过上述维度钻取分析，可发现系统响应时间突高的故障现象，是由于某渠道发起的“委托交易”导致。
最后，根据已经锁定的异常渠道的异常交易，针对客户号追踪分析，找出异常交易的客户账号，追溯到客户级别的根因。
综上，在应急演练的融资融券业务异常的场景中，运用旁路业务监控系统，通过对原始报文全量回溯分析，定位关键KPI指标，并进行多维钻取分析，最终诊断耗时异常是由于个别客户的委托交易耗时过长导致，在此基础上，调出异常事件的问题交易参数，进行精确分析，从而定位问题根因，极大提升了运维人员排障效率。
四、总结和展望
旁路业务监控系统在兴业证券上线近两年，部署在集团两地三中心，通过对基础设施所支撑的集中交易系统进行旁路网络流量采集、重组、关联分析，实现集中交易系统报盘、接入AR、BAR、LS、AS、DB数据库等组件的全链路端到端的可视化管理，协助运维人员精准快速定位故障节点，解决了困扰多年的故障重现难题，大幅提升排障效率。
网络流量旁路关联分析技术在未来的应用空间广阔，可以为大数据平台提供全量数据，结合大数据技术深入分析交易过程瓶颈。另外，可结合AI技术和业务模型，在业务预测、容量规划、用户体验分析、智能故障发现定位、自动根因分析等方面发挥重要的作用。
未来兴业证券积极探索前沿科技与数字基建的数智化转型，加速推进集团智能运维体系升级，推动科技对集团客户服务、业务发展与经营管理的全面赋能。