地震预警^[1]，是指在地震发生后，利用地震波传播速度小于电波传播速度的特点，提前对地震波尚未到达的地方进行预警。

地震预警系统全链条自动化的运行模式^[2-3]，对运行质量监测管理也提出了更高的要求，体现在以下五个方面：

（1）全流程全过程监测：从传统的IP仪器、通讯线路、服务器的单点、单维度监测，变成对业务系统整体运行状态、数据传输全流程、应用响应全过程的监测；

（2）数据实时动态更新：需要实时监测网络带宽占用、网络传输稳定性、网络时延^[4]、数据路由变化、业务系统各类应用与服务响应时间等新型信息；

（3）异常发现更快速：需对系统数据传输、主机性能、应用响应、服务响应的情况实现秒级跟踪，能在分钟级内发现系统异常；

（4）隐患定位更精准：能基于网络流量数量，结合业务拓扑，快速从异常状态中定位到隐患位置，包括网络设备、服务器与工作站主机、应用程序、业务组件、通讯协议、服务端口等^[5]；

（5）对业务系统运行无影响：监测管理不能额外对业务系统运行环境产生影响，具备无感监测或旁路监测能力。

传统的系统运维监测管理工具，大多数使用SNMP协议或自有Agent进行管理，它们对于地震预警系统运行质量的监测管理都有较大的局限性。

SNMP协议在网络管理中被广泛使用，优势在于覆盖范围广使用成本低，各类IT设备与操作系统基本属于出厂配置。但其不适合大规模应用，除安全性外，最为关键的是SNMP协议的性能问题。在大型系统中，SNMP协议设置的响应时间一般在分钟级或更久，实时性不足，而如果将数据采集频率提高，则协议本身对于宿主设备或系统将带来负载压力，同时，很多IT设备与系统的MIB私有化，所能监测的数据种类、数据精度受限，不能提供新型监测数据。

SNMP协议属于具备Agent的应用模式，传统监测管理工具还有Agentless的应用模式，即不需要在被监测管理的系统上安装特定的Agent，表1是对两种应用模式的对比分析。

通过以上分析，可以看出系统运维监测管理工具由于响应时间、应用模式、业务运行质量运行质量状态数据获取等限制，都无法适应地震预警系统的运行质量监测管理要求。

表1 监测系统数据采用Agent与Agentless的区别Table 1 Difference between using Agent and Agentless for monitoring system data

网络性能监控和诊断（NPMD）^[6]技术实时分析各种协议的网络数据包，使用数据包数据、流量数据和基础设施度量指标^[7-8]，可实时掌握网络及在网络上运行的应用程序的可用性和性能，可快速分析识别业务性能下降的原因，并可提供历史、实时和可预测性的分析视图。

NPMD技术对于运行环境高稳定性、数据处理高实时性、运行状态极低的错误率的业务运行质量监测管理要求有较好保障能力。因此，作者认为基于NPMD技术的监测系统，可以满足地震预警业务系统的运行质量监测管理要求^[9]。

作者在研究NPMD技术期间，正在从事河南省地震烈度速报与预警系统建设，针对地震预警系统的重要性，作者采用旁路数据采集方式获取地震预警系统的运行状态数据，在不对业务系统产生任何影响的情况下，测试验证NPMD技术的实际应用情况。

作者在测试工作中，设计采用了某公司的UPM系统（业务性能管理系统），主要包括两大部分组成，即网络流量分析系统（即数据采集前端）和业务性能监测与分析中心（UPM分析中心）。

（1）网络流量分析系统（数据采集前端）。网络回溯分析系统实时采集、分析、统计及存储网络数据，配备有大容量存储的高性能数据包采集和前端分析设备，可部署在网络中的关键节点，实现对网络数据包的高性能实时采用和快速分析，它是NPMD系统中的前端数据获取组件。

（2）业务性能监测与分析中心（UPM分析中心）。业务性能监测与分析中心是面向业务的综合性能监测管理分析平台，它可以集中收集分布式部署在网络各个节点的网络回溯分析系统（数据采集前端）中的实时数据，以图形化、图表化的方式呈现业务系统各个环节的工作状况，全面监控业务系统各环节服务质量、快速发现并定位影响关键业务性能或稳定性问题的核心系统。

表2所述内容，是作者对于UPM系统在地震预警系统运行质量监测管理工作中的功能测试要求。

作者设计的系统测试环境如图1所示，详细情况如下。

（1）部署1台网络流量分析系统，提供4个10 G接口进行4路网络数据采集，实现测试数据较全覆盖，4路数据如表3所示；

（2）部署1台UPM分析中心，与网络流量分析系统对接，进行测试环境中的业务运行质量监测分析，并通过WEB提供分析结果应用；

表2 NPMD测试系统主要验证能力设计Table 2 Design of main verification capabilities for NPMD test system

（3）核心路由器为地震预警业务系统核心路由，汇聚本地及行业的地震预警业务流量；

（4）边界防火墙，将路由器汇聚的数据，根据安全策略设置，安全分发至相关网络域；

（5）核心交换机（内置防火墙），属于核心业务系统的交换系统，提供核心业务系统的网络连接与安全控制；

（6）应用服务器与维护工作站，是核心业务服务与日常管理、维护工作站设备，相关地震预警业务部署运行于其中；

（7）TAP流量盒，实现网络数据复制，实现网络流量旁路分流效果。

通过此种部署方式，可实现地震预警系统中地震台—省中心—国家中心/国家备份中心/邻省中心的数据传输和预警关键业务的监测范围覆盖。

测试系统1天部署完成，系统的部署、流量采集配置等环节在此不再赘述。

图1 测试系统拓扑图Fig.1 Test system topology

表3 NPMD测试系统数据采集设计Table 3 Design of data collection for NPMD test system

由于NPMD技术更多是进行业务系统的运行质量监测管理，所以在系统正式使用前，要在测试的UPM系统中，建立准确的业务系统信息，包括支撑业务系统的网络环境、网络拓扑、业务服务器、业务工作站等内容。

在测试系统部署上线后，作者在系统中，使用UPM系统业务访问关系自动发现与梳理功能，快速配置出测试环境中的所能监测的业务系统信息，包括如下内容。

（1）200个基本站、基准站的通信网络；

（2）河南省中心至国家地震台网中心通信网络；

（3）河南省中心至国家备份中心通信网络；

（4）16个地震预警业务核心服务器；

（5）1个地震预警业务运维工作站；

（6）3个地震预警台站节点业务系统

并基于以上监测信息，设计了台站节点在线情况多维度监测、通信链路高精度监测、业务系统运行质量监测、业务核心性能指标监测、综合业务性能监测等场景。

在系统上线配置完成后，经过3个月的运行验证，各项测试结果达到表2预期目标。实现对地震预警系统业务运行质量与运行状态的智能感知、关键性能指标分析、运行异常状态研判与报警以及场景化可视化展现等，且测试工作未对地震预警系统产生任何影响。详细情况如下。

3.3.3 通信链路服务质量多维度监测分析

利用预警业务系统中台站节点与省中心实时交换的数据，实现对通信链路及其承载的重要业务的高精度监测，包括线路延时、带宽占用、数据重传、数据丢包率、网络抖动等信息，对于通信链路质量管理实现有效支撑。

图2 业务系统运行质量监测分析Fig.2 Monitoring and analysis of operation quality of business system

图3 业务核心性能指标监测Fig.3 Monitoring of core business performance indicators

图4 业务系统精细化监测指标应用Fig.4 Application of refined monitoring indicators of business system

图5 关键设备数据传输延时监测Fig.5 Delay monitoring of key equipment data transmission

图6 台站节点在线状态监测与故障分析Fig.6 Online status monitoring and fault analysis of station nodes

图7是通过数据分析，建立的预警台站数据流监控界面，其中包括了网络链路+业务数据流量两类监测信息。

图8是对省级预警中心与国家中心、国家备份中心进行的核心链路监控，除链路的连通性外，还包括了链路比特率、TCP分段丢失率等重要的链路服务质量信息，以及在链路上承载的关键业务的网络延时和网络重传率等关键信息。

图7 台站节点与业务数据流监测分析Fig.7 Monitoring and analysis of station nodes and business data flow

图8 重要链路及承载业务的运行质量监测分析Fig.8 Monitoring and analysis of operation quality of important links and bearer services

在图1所示的网络环境中，为了增加预警业务系统边界的整体防护能力，将边界防火墙采用性能更高、功能更强的设备进行了替换，替换完成后，运行质量监测工具提示出现异常，并将异常位置确定为新替换的边界防火墙区域。

运行质量监测工具提示的详细告警信息，包括业务系统中出现的网络连接失败率增加、网络会话数快速增长、TCP报文量不正常变化等，如图 10所示。

图9 业务系统运行质量可视化跟踪与管理Fig.9 Visual tracking and management of operation quality of business system

图 10 系统故障监测——应用性能多维异常Fig.10 System fault monitoring multi-dimensional anomaly of application performance—

运维人员在验证关键业务后，发现通过预警系统中的运维工作站与预警台站节点的仪器进行WEB界面访问时，出现严重超时问题，且系统响应持续不稳定。根据此情况，运维人员又在边界防火墙右侧核心业务区进行内部测试，一切正常，台站节点运维人员在边界防火墙左侧进行外部应用测试，一切正常。因此，初步判定，在新的边界防火墙上线后，影响了部分使用HTTP协议的业务应用，运行质量监测工具报警有效。

确定了故障位置后，对新上的边界防火墙做了以下确认工作，如表4所示。

表4 防火墙系统验证过程Table 4 Firewall system verification process

完成以上验证工作后，认为迁移过程中，防火墙策略配置无误，系统运行正常，且仅对部分使用HTTP协议的业务系统有影响，认为需要进行为精细的分析排查。

通过运行质量监测工具对异常期间的数据进行精细分类后，发现系统中与核心业务区域21.X. X.11的数据交换，频繁出现连接失败率较高情况。

进一步对连接较多的会话（21.x.x.11—21.x.x.1）进行时序分析，发现在业务系统存在TCP超长时间响应，下图所示为24 s内未收到回复，在此情况下，一方发送FIN包主动断开连接，随后21.X.X.1尝试恢复链接直至链接恢复。在此期间内出现网络流量大幅下降。

此外发现在会话中，数据包中存在大量的重传和乱序包，大量的乱序包会导致系统延迟降低响应时间，如图 13所示。

图 11 系统故障监测——网络连接失败率异常Fig.11 System fault monitoring abnormal network connection failure rate—

图 12 系统故障监测——TCP会话链接异常Fig.12 System fault monitoring abnormal TCP session link—

图 13 系统故障监测——数据包乱序与重传Fig.13 System fault monitoring packet disorder and retransmission—

根据以上情况，认为新上线的边界防火墙在TCP流量控制中和原有防火墙存在不同，随后将系统异常排查重点放到新防火的TCP控制类参数中。

经过与防火墙厂商的详细排查，将新防火墙系统中的【TCP连接完整性】调整为关闭状态，并打开【允许非SYN包建立连接】后，各业务系统访问恢复正常，运行质量监测工具不再进行异常报警。

查阅资料，新防火墙的【TCP的连接完整性】状态打开时，设备会跟踪TCP连接的状态，TCP连接必须通过完整的三次握手，防火墙才允许其建立连接；TCP连接经过四次结束握手或者收到RST数据包，防火墙才终结其连接。

在地震预警系统中，台站节点中的部分HTTP服务，在TCP设计中，可能未完全进行TCP连接完整性设计，因此在新防火墙上线后，会造成对此类HTTP服务访问时的TCP会话异常。

此次系统异常处置中，基于NPMD技术的运行质量监测工具，实现了传统运维系统无法发现的业务异常，且早于人工发现，并自动定位故障点，基于数据包级的详细数据，支撑问题的快速分析与研判，大大缩短处置时间。