CN116962143A - 网络故障检测方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种网络故障检测方法、装置、计算机设备、存储介质和计算机程序产品。所述方法包括：获取网络探测数据；所述网络探测数据通过按照指定的探测路径对广域网络进行网络探测而得到；确定与各所述网络探测数据分别对应的路径相关信息；所述路径相关信息指示了网络探测数据所来源的探测路径；针对任一级别的故障类型，从所述网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于所述指定探测数据进行故障检测；根据各级别故障类型分别对应的检测结果，确定网络检测结果。采用本方法能够提高网络故障检测的准确性。本发明实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景。

Description

网络故障检测方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种网络故障检测方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

数据中心作为数字网络的支柱，对信息业务、云服务、应用数据内容等均可以提供存储和计算资源。当前企业新兴业务及用户数字生活也变得更加依赖数据中心。为了满足企业多业务支撑和用户跨地域高质量网络体验的需求，数据中心需要通过互连以共享或备份数据，实现负载均衡，据此产生了数据中心互联（DCI，Data Center Interconnect）网络。

DCI网络具有多平面、密连线的特点，其中的网络规模庞大、网络中的传输线路复杂缭绕，为网络故障检测带来了一定的挑战。若DCI网络中某些路线发生故障，故障所在的位置往往难以准确定位。传统的网络故障检测方式通常是根据路由表进行故障定位，但这种方式往往会花费大量的时间，特别是在DCI网络场景中，无法满足网络故障实时定位和快速响应的需求，存在网络检测时效性低的问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高网络故障检测准确性的网络故障检测方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种网络故障检测方法。所述方法包括：

获取网络探测数据；网络探测数据通过按照指定的探测路径对广域网络进行网络探测而得到；

确定与各网络探测数据分别对应的路径相关信息；路径相关信息指示了网络探测数据所来源的探测路径；

针对任一级别的故障类型，从网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于指定探测数据进行故障检测；

根据各级别故障类型分别对应的检测结果，确定网络检测结果。

第二方面，本申请还提供了一种网络故障检测装置。所述装置包括：

数据获取模块，用于获取网络探测数据；网络探测数据通过按照指定的探测路径对广域网络进行网络探测而得到；

路径信息确定模块，用于确定与各网络探测数据分别对应的路径相关信息；路径相关信息指示了网络探测数据所来源的探测路径；

故障检测模块，用于针对任一级别的故障类型，从网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于指定探测数据进行故障检测；

检测结果确定模块，用于根据各级别故障类型分别对应的检测结果，确定网络检测结果。

第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述网络故障检测方法的步骤。

第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述网络故障检测方法的步骤。

第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述网络故障检测方法的步骤。

上述网络故障检测方法、装置、计算机设备、存储介质和计算机程序产品，针对广域网络，预先设定对其进行网络探测的多条指定的探测路径，进而可按照指定的探测路径进行网络探测以获得网络探测数据。每个网络探测数据都分别对应有其来源的探测路径的路径相关信息。这样，在分级进行不同级别的故障检测时，可以根据任一故障类型所匹配的路径相关信息，找到相关联的指定探测数据，进而就可集中性、且有针对性的进行该故障类型对应的故障检测。结合各级别故障类型分别对应的检测结果，就能确定整个广域网络的网络检测结果了。这样，通过对不同级别的故障类型进行针对性的检测，可以认为是将广域网络进行了分解，将其切分为更小的单元进行针对性的检测，从而便于快速发现故障所在的节点和链路。这种方式可以大大降低网络检测的故障域，提高故障隔离和定位的速度和准确度，减少网络故障对业务的影响，具有非常重要的现实意义。

附图说明

图1为一个实施例中网络故障检测方法的应用环境图；

图2为一个实施例中网络故障检测方法的流程示意图；

图3为一个实施例中网络探测数据获取步骤的流程示意图；

图4为一个实施例中广域网络的架构示意图；

图5为另一个实施例中广域网络的架构示意图；

图6为一个实施例中告警信息展示示意图；

图7为另一个实施例中告警信息展示示意图；

图8为一个实施例中网络故障检测方法的流程框图；

图9为一个实施例中告警信息统计结果示意图；

图10为一个实施例中网络故障检测装置的结构框图；

图11为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请实施例提供的网络故障检测方法，可以应用于如图1所示的应用环境中。其中，计算机设备102通过网络与各不同的园区内部署的探测设备104进行通信。数据存储系统可以存储计算机设备102需要处理的网络探测数据。数据存储系统可以集成在计算机设备102上，也可以放在云上或其他服务器上。需要说明的是，各不同的园区可以为不同城市的园区，如园区1处于城市A中，园区2处于城市B中，园区3处于城市C中，以及园区N处于城市D中等。各不同的园区也可以部分处于相同的城市，如园区1和园区2均处于城市A，园区3和园区N处于城市B中。

在本申请中，各不同的园区内部署的探测设备可以按照指定探测路径发送探测流，计算机设备102可获取到通过探测流探测得到的网络探测数据，进而执行本申请各实施例所提供的网络故障检测方法。具体地，在网络故障检测的过程中，计算机设备102可以确定各不同园区内部署的探测设备104发送的网络探测数据分别对应的路径相关信息；网络探测数据对应的路径相关信息指示了所来源的探测路径；计算机设备102可以针对任一级别的故障类型，从网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于指定探测数据进行故障检测；根据各级别故障类型分别对应的检测结果，确定网络检测结果。

其中，计算机设备102具体可以是终端或者服务器。其中，终端可以但不限于是各种台式计算机、笔记本电脑、智能手机、平板电脑、物联网设备、便携式可穿戴设备、智能语音交互设备、智能家电、车载终端、飞行器等。物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接。本发明实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。

其中涉及的云技术（Cloud technology）是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

人工智能(Artificial Intelligence, AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。换句话说，人工智能是计算机科学的一个综合技术，它企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。人工智能也就是研究各种智能机器的设计原理与实现方法，使机器具有感知、推理与决策的功能。

人工智能技术是一门综合学科，涉及领域广泛，既有硬件层面的技术也有软件层面的技术。人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。

下面对本申请的网络故障检测方法进行详细的介绍：

在一个实施例中，如图2所示，提供了一种网络故障检测方法，该方法可以由如图1所示的计算机设备执行，在本申请实施例中，以该计算机设备为服务器为例进行说明，该方法包括以下步骤：

步骤202，获取网络探测数据；网络探测数据通过按照指定的探测路径对广域网络进行网络探测而得到。

其中，广域网络是实现计算机通信的远程网，广域网络可以跨接较大的物理范围，能为多个地区、城市提供远距离通信。广域网络具体可以是包括城域多平面和骨干多平面的多平面架构的网络，通过这种多平面的架构，可以实现高容量和高质量的网络服务。通过广域网络可以实现园区内的通信、以及各园区之间的通信。例如，基于广域网络可以实现同一园区内的园区内信息交互、同一城市不同园区之间的信息交互、以及处于不同城市的园区之间的信息交互等。

在一些实施例中，广域网络为三维立体网络，由部署于不同城市的不同园区内的网络节点、各城市分别对应的城域多平面、以及骨干多平面互联构成。

探测路径是针对广域网络进行网络探测的路径，通过在设定的探测路径中传输探测流，可以得到与探测路径对应的网络探测数据。探测路径可以包括从起点到终点的全程路由，即通过全程路由，可以明确探测流的发送设备、接收设备、从发送到接收所途径的各城域平面、骨干平面以及网络设备等信息。

在广域网络中，探测路径具体可以定义为设置于园区内的探测设备所发送的探测流在广域网络中的全程路由。探测路径可以覆盖广域网络中每一个城域平面、骨干平面以及城域平面与骨干平面之间的链路，探测路径也可以只覆盖广域网络中部分的城域平面、骨干平面以及城域平面与骨干平面之间的链路。

在实际指定探测路径时，可以结合实际所需要进行网络故障检测的需求、广域网络的规模等进行适应性调整。基于网络故障检测需求，探测路径可以划分为两种类型的路径，也就是城域内探测路径和跨城域探测路径，城域内探测路径是通过处于同一城市的不同园区的探测设备之间进行网络探测的路径；跨城域探测路径是通过处于不同城市的园区的探测设备之间进行网络探测的路径。通过指定探测路径，可以针对性的定位到进行网络故障检测的广域网络区域，提升网络故障检测的准确性和精度。

网络探测数据是反映网络状态的数据，本申请所涉及到的网络探测数据具体可以为对广域网络的网络状态进行探测而得到的数据，可以用于实时分析广域网络中潜在的多种网络风险。

具体地，服务器可以获取按照指定的探测路径对广域网络进行网络探测而得到网络探测数据。网络探测数据与指定的探测路径相关，服务器可以基于网络故障的检测需求指定相匹配的探测路径，使得可以按照指定的探测路径传输探测流以监测广域网络的网络状态，得到网络探测数据。针对多平面网络架构的广域网络，可以指定多个探测路径，以使得服务器可以对广域网络进行全面准确的故障检测。

在一些实施例中，服务器在获取网络探测数据时，可以直接将按照指定的探测路径进行探测得到的原始探测数据作为网络探测数据，也可以对原始探测数据进行处理后得到网络探测数据。其中，在对原始探测数据进行处理时，具体可以是对原始探测数据进行修正、去噪等处理，以提升后续进行网络故障检测的精度。

在一个实施例中，在按照指定的探测路径中传输的探测流可以包括两种类型的探测流：城域内探测流和跨城域探测流，服务器获得的网络探测数据可以包括城域内探测流对应的网络探测数据、以及跨城域探测流对应的网络探测数据。

在一些实施例中，所有指定的探测路径所经过的网络节点的并集，为该广域网络内所有的网络节点的集合。当然，在一些其他的实施例中，由所有指定的探测路径所经过的网络节点的并集而构成的集合，其集合内的网络节点为该广域网络内的部分网络节点。

需要说明的是，对于多平面架构的广域网络，在指定探测路径时，针对同一城市不同园区间的通信、不同城市园区间的通信，均可以有多种可选的探测路径。例如，假设广域网络中的城域平面包括多个城域平面和多个骨干平面，则可以指定不同的城域平面、骨干平面组合得到探测路径。

步骤204，确定与各网络探测数据分别对应的路径相关信息；路径相关信息指示了网络探测数据所来源的探测路径。

其中，路径相关信息是用于对网络探测数据所来源的探测路径进行描述的信息，具体可以包括探测路径的路径类型、所传输的探测流类型、或探测路径所经过的网络节点的节点信息等。路径类型可以与探测流类型对应，探测流类型具体可以包括城域内探测流和跨城域探测流，城域内探测流是在城域内探测路径中传输的探测流，跨城域探测流是在跨城域探测路径中传输的探测流。

网络节点是构成广域网络的节点，通过通信线路将多个网络节点连接起来即可形成广域网络。网络节点具体可以为拥有自身的网络地址，且能实现通信功能的设备，如工作站、终端设备、服务器或其他任意用于网络连接的网络设备。

节点信息是用于描述某个网络节点的信息，具体可以是节点标识，和/或描述节点属性的信息，在呈现上可以由字母、数字、特征码等任意标识符表示。网络节点的节点属性可以包括网络节点的节点类型、网络节点所处广域网络中的位置以及网络节点的节点参数等多种信息。网络探测数据中携带的节点信息，可以反映出其所来源的探测路径经过的网络节点，通过确定出网络节点，可以快速定位出故障所在的位置。具体地，针对每个网络探测数据，服务器可以根据网络探测数据所来源的探测路径，来确定与该网络探测数据相对应的路径相关信息。

在一些实施例中，路径相关信息包括节点信息，节点信息中可以包括节点标识信息，服务器在根据节点信息确定所来源的探测路径经过的网络节点时，可以基于节点信息获得节点标识信息，并基于节点标识信息，确定所来源的探测路径经过的网络节点。

步骤206，针对任一级别的故障类型，从网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于指定探测数据进行故障检测。

其中，故障类型可以是广域网络中存在的故障的类型，由于广域网络规模庞大的特点，广域网络可以包括有多种级别的故障。在划分故障类型时，可以按照区域进行划分，如按照故障所处广域网络的区域展开划分；也可以按照故障的影响程度进行划分，还可以按照网络节点的类别展开划分，或者是属于软件故障还是硬件故障展开划分。

如在按照区域划分故障类型时，可以基于城域内、跨城域为基准展开划分，即划分为城域内故障和跨城域故障。按照故障所处广域网络的区域展开划分时，可将其分为探测设备故障、城域平面内故障、骨干平面内故障、第一链路故障、以及第二链路故障；其中，第一链路为园区内网络节点与城域平面内的网络节点之间的网络链路，第二链路为城域平面内的网络节点与骨干平面内的网络节点之间的网络链路。

具体地，服务器针对每一个级别的故障类型，均可以基于网络探测数据中的路径相关信息，从网络探测数据中选取出与故障类型匹配的数据作为指定探测数据，并基于指定探测数据进行故障检测。

在一些实施例中，路径相关信息包括路径类型，每种故障类型关联至少一个路径类型。故而，服务器可以按照当前待进行故障检测的故障类型，确定出当前匹配的路径类型，再从网络探测数据中筛选出与当前的路径类型对应的探测数据作为指定探测数据。

在另一些实施例中，路径相关信息包括路径标识，每种故障类型关联至少一种路径标识。故而，针对任一故障类型，服务器可确定与所针对的故障类型相关联的路径标识，并基于该路径标识，从网络探测数据中筛选出携带有该路径标识的探测数据作为指定探测数据。

在一些实施例中，节点信息包括节点类型，每种故障类型关联至少一个节点类型。故而，服务器可以按照当前待进行故障检测的故障类型，确定出当前的节点类型，再从网络探测数据中筛选出携带有当前的节点类型的探测数据作为指定探测数据。

在另一些实施例中，节点信息包括节点标识，每种故障类型关联至少一种节点标识。故而，针对任一故障类型，服务器可确定与所针对的故障类型相关联的节点标识，并基于该节点标识，从网络探测数据中筛选出携带有该节点信息的探测数据作为指定探测数据。

在一些实施例中，针对每一类故障类型的故障检测，可以采用相同的检测方式展开检测，也可以采用不同的检测方式展开检测。检测方式具体可以是分析丢包率、或查询路由表等。

步骤208，根据各级别故障类型分别对应的检测结果，确定网络检测结果。

具体地，服务器可以针对每一级别的故障类型，确定与其对应的检测结果，并基于各检测结果，确定网络检测结果。服务器在根据各检测结果确定网络检测结果时，可以对各故障类型对应的检测结果进行缓存、汇总分析等处理，以确定在广域网络中故障所在的网络节点、链路等。

上述网络故障检测方法中，针对广域网络，预先设定对其进行网络探测的多条指定的探测路径，进而可按照指定的探测路径进行网络探测以获得网络探测数据。每个网络探测数据中分别对应有其来源的探测路径的路径相关信息。这样，在分级进行不同级别的故障检测时，可以根据任一故障类型所匹配的路径相关信息，找到相关联的指定探测数据，进而就可集中性、且有针对性的进行该故障类型对应的故障检测。结合各级别故障类型分别对应的检测结果，就能确定整个广域网络的网络检测结果了。这样，通过对不同级别的故障类型进行针对性的检测，可以认为是将广域网络进行了分解，将其切分为更小的单元进行针对性的检测，从而便于快速发现故障所在的节点和链路。这种方式可以大大降低网络检测的故障域，提高故障隔离和定位的速度和准确度，减少网络故障对业务的影响，具有非常重要的现实意义。

在一个实施例中，如图3所示，针对网络探测数据的获取，包括以下步骤：

步骤302，获取按照指定的探测路径对广域网络进行网络探测得到的原始探测数据。

其中，原始探测数据是指未经处理过的探测数据，即按照指定的探测路径对广域网络进行网络探测得到的数据。

在一些实施例中，指定的探测路径可以包括探测路径1、探测路径2…以及探测路径N等多条探测路径，服务器可以获取通过每条探测路径进行网络探测得到的原始探测数据。

在一些实施例中，服务器可以直接基于获取的原始探测数据进行网络故障检测，以节省计算资源。为了提升网络故障检测的精度，服务器也可以对原始探测数据进行修正、去噪等处理之后再进行网络故障检测。

步骤304，提取原始探测数据中的增量探测数据；增量探测数据表征存在丢包现象。

具体地，为了降低探测数据的处理量，在订阅探测数据时，可只关注有丢包现象的探测数据，也即从原始探测数据中提取出表征存在丢包现象的增量探测数据。

在一些实施例中，增量探测数据可以是由广域网络自身故障导致的，如广域网络中的网络节点出现故障、网络节点构成的链路出现故障等因素导致。增量探测数据也可以是由除广域网络自身故障以外的其他因素导致的，如网络抖动、上报延迟、或探测设备自身发生故障等因素。

在一些实施例中，服务器在从原始探测数据中提取增量探测数据时，可以先确定原始探测数据的丢包率，通过对原始探测数据中的丢包率进行分析，将原始探测数据中的丢包率满足预设丢包判断条件的数据确定为增量探测数据。其中，预设丢包判断条件可以是根据丢包率阈值设定的条件，具体可以为当丢包率达到丢包率阈值时，确定满足预设丢包判断条件。丢包率阈值可以设定为1%，也可以设定为2%等其他数值，丢包率阈值的设定可以结合网络状态、网络故障检测的精度需求等进行适应性调整，本申请实施例对此不作限定。

步骤306，对增量探测数据进行去干扰调整，得到调整后的增量探测数据。

其中，去干扰调整是对出现丢包现象的增量探测数据进行处理，从而降低对网络故障检测的干扰的操作。

具体地，服务器可以对从原始探测数据中提取到的增量探测数据进行去干扰调整，得到调整后的增量探测数据。服务器在进行去干扰调整时，可以从不同的维度进行调整。

在一些实施例中，服务器可以从时间维度上对增量探测数据进行调整，即按照各增量探测数据所对应的时间戳对增量探测数据进行排序，以使得调整后的增量探测数据是按照时间顺序进行排列的。

在另一些实施例中，服务器还可以从数据包维度上对增量探测数据进行调整，对可能存在错误的丢包率进行修正。

步骤308，基于调整后的增量探测数据、以及原始探测数据，确定用于进行故障检测的网络探测数据。

具体地，服务器可以整合调整后的增量探测数据、以及原始探测数据，得到网络探测数据。

举例说明，在基于探测路径1、探测路径2…以及探测路径N等多条探测路径进行网络探测得到的原始探测数据中，存在探测路径1、探测路径2对应的原始探测数据存在丢包现象，服务器可以确定探测路径1、探测路径2对应的原始探测数据为增量探测数据。服务器可以分别针对探测路径1、探测路径2对应的增量探测数据进行去干扰调整，得到调整后的增量探测数据，再结合其他无需进行调整的原始探测数据，得到网络探测数据。

上述实施例中，通过对存在丢包现象的增量探测数据进行去干扰调整，得到调整后的增量探测数据，并基于调整后的增量探测数据、以及原始探测数据，确定网络探测数据。这样可针对影响网络故障分析的干扰因素进行剔除，从而大大提高后续网络故障检测的准确性。

在一个实施例中，对增量探测数据进行去干扰调整，得到调整后的增量探测数据，包括：对增量探测数据进行丢包率修正，得到修正后的增量探测数据；将修正后的增量探测数据按照时序进行拆分，并将拆分后的数据放入时间处理队列；提取预设检测周期内时间处理队列中的数据，得到调整后的增量探测数据。

其中，丢包率是增量探测数据所丢失的数据包数量占所发送数据包的比率。丢包率修正是对增量探测数据的丢包率进行调整。

时间处理队列可以是具有时间顺序的，设定的用于缓存增量探测数据的队列，在时间处理队列中，修正后的增量探测数据可以是按照自身的时间戳进行排序的。

预设检测周期是设定的对广域网络进行网络故障检测的周期，预设检测周期可以为预先设定的时间间隔，比如1小时、1天或一周等，具体可以结合实际的网络故障检测需求等进行适应性的设定。

在一些实施例中，服务器可以只选取部分增量探测数据进行修正，也可以选择对全部增量探测数据进行修正。具体选取进行丢包率修正的增量探测数据可以结合增量探测数据的丢包情况确定。

在一些实施例中，对增量探测数据进行丢包率修正，得到修正后的增量探测数据，包括：针对任一探测路径，在与所针对的探测路径对应的原始探测数据中存在丢包情况不一致的情况下，对与所针对的探测路径对应的增量探测数据进行丢包率修正，得到修正后的增量探测数据。

需要说明的是，同一探测路径传输的探测流可以是多条，比如2、4条或6条等，同一探测路径传输的不同探测流的个数可以取决于收发探测流的探测设备的个数，收发探测流的探测设备的个数可以结合成本、对网络故障检测结果的精度需求等进行设定。

在一些实施例中，为了提升探测的精度，园区内会安排一对探测设备进行双活探测，以避免探测设备出现故障而导致的误判问题。因此，当源/目的中的一对探测设备出现探测结果不一致时，需要针对探测结果进行修正，也就是对增量探测数据进行修正，避免单台探测设备故障而对整个探测结果造成影响。

在一些实施例中，针对源/目的中的一对探测设备出现探测结果不一致的情况，服务器在进行增量探测数据的修正时，可以对增量探测数据的丢包率进行调整，具体可以将增量探测数据的丢包率调整为丢包率设定值，使得修正后的增量探测数据表征不存在丢包现象，丢包率设定值可以为0，也可以为其他任意使得增量探测数据表征不存在丢包现象的值。

例如，针对探测路径为园区A到园区B的路径，园区A中发送探测流的探测设备为2个，如源探测设备a1和源探测设备a2。园区B中接收探测流的探测设备的个数也为2个，如目的探测设备b1和目的探测设备b2。那么基于此，针对这一条探测路径，则会存在4个原始探测数据，即从源探测设备a1分别发送至探测设备b1和目的探测设备b2两个原始探测数据，源探测设备a2分别发送至探测设备b1和目的探测设备b2的两条原始探测数据。服务器可以分别获取这4个原始探测数据进行丢包情况分析，看其中是否存在丢包率不一致的情况。若存在，可以表示存在故障的探测设备，故而对存在丢包现象的增量探测数据进行丢包率的修正。

上述实施例中，服务器在确定所针对的探测路径对应的原始探测数据中存在丢包情况不一致的情况下，对与所针对的探测路径对应的增量探测数据进行丢包率修正，得到修正后的增量探测数据。可以修正明确是由收发探测流的探测设备故障引起的丢包现象，降低了网络故障检测的干扰，提升了网络故障检测的精度。

更进一步地，由于上报的增量探测数据可能来自不同的园区，考虑到上报延迟、网络抖动等各种因素，订阅的增量探测数据可能会出现乱序。为了解决这个问题，本申请将修正后的增量探测数据按时间戳进行拆分，之后放入时间处理队列中。在此基础上，可针对每个预设周期的增量探测数据设置最长延迟等待时间，如果对应预设周期的数据超过该最长延迟等待时间才被消费到，则会被直接丢弃。当某个预设周期的增量探测数据接收窗口关闭后，结合该预设周期内的原始探测数据，就能得到对应周期的完整的网络探测数据。

将按照时间拆分后的数据放入时间处理队列，后续在进行数据提取时可以基于划分出的时间信息进行数据提取，提高了数据提取的效率；同时也便于数据管理，即通过时间戳对增量探测数据分区使得数据的插入、删除和维护更加的方便。

上述实施例中，服务器通过对增量探测数据进行丢包率修正，得到修正后的增量探测数据，将修正后的增量探测数据按照时序进行拆分，并将拆分后的数据放入时间处理队列，结合预设检测周期，从时间处理队列提取得到调整后的增量探测数据。通过对增量探测数据进行丢包率调整、时间处理等去干扰调整，得到调整后的增量探测数据，可以提高故障隔离和定位的速度和准确度，减少网络故障对业务的影响，具有非常重要的现实意义。

在一个实施例中，针对任一级别的故障类型，从网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于指定探测数据进行故障检测，包括：针对任一级别的故障类型，确定与所针对的故障类型相关的路径类型；从网络探测数据中筛选出指定探测数据；指定探测数据所来源的探测路径的路径类型与所针对的故障类型相关；基于指定探测数据进行所针对的故障类型的故障检测。

其中，路径类型是探测路径的类型，探测路径所覆盖广域网络的覆盖区域不同，其路径类型也可以不同，如路径类型可以包括城域内探测路径、跨城域探测路径等。

对于每一级别的故障类型，均对应有与之相关的路径类型，通过故障类型相关的路径类型，可以从网络探测数据中提取得到与故障类型匹配的指定探测数据。

具体地，服务器可以针对任一级别的故障类型，确定与所针对的故障类型相关的路径类型，基于路径类型从网络探测数据中筛选出指定探测数据，指定探测数据的路径相关信息所指示的路径类型与所针对的故障类型相关，并基于确定出的指定探测数据进行所针对的故障类型的故障检测。

在一些实施例中，对于探测设备故障，与其相关联的路径类型可以是城域内探测路径和跨城域探测路径；对于城域平面故障，与其相关联的路径类型可以是城域内探测路径；针对骨干平面故障，与其相关联的路径类型可以是跨城域探测路径等；对于第一链路故障，与其相关联的路径类型可以是城域内探测路径、跨城域探测路径等；对于第二链路故障，与其相关联的路径类型可以是跨城域探测路径等。

比如，服务器在确定探测设备故障对应的指定探测数据时，可以获取与探测设备相关的城域内探测路径、跨城域探测路径对应的网络探测数据作为指定探测数据；服务器在确定城域平面故障对应的指定探测数据时，可以获取城域平面相关的城域内探测路径对应的网络探测数据作为指定探测数据。

上述实施例中，服务器可以针对任一级别的故障类型，从路径相关信息中确定与所针对的故障类型相关的路径类型，基于路径类型从网络探测数据中筛选出指定探测数据，并基于确定出的指定探测数据进行所针对的故障类型的故障检测，通过对不同级别的故障类型进行针对性的检测，便于快速发现故障所在的节点和链路。

在一个实施例中，不同级别的故障类型对应不同的检测顺序，若所针对的故障类型的检测顺序为非首位，则基于指定探测数据进行所针对的故障类型的故障检测，包括：确定由在前的故障检测而获得的故障探测流；从指定探测数据中剔除掉故障探测流，并基于剔除故障探测流后的探测数据进行所针对的故障类型的故障检测。

其中，检测顺序是指对各故障类型进行故障检测的顺序，检测顺序可以与故障类型的级别相关，如故障类型的级别越低，检测顺序越在前，或者故障类型的级别越高，检测顺序越在前。

在一些实施例中，故障类型的级别是根据故障类型相关的探测流在广域网络中的覆盖范围确定的，探测流的覆盖范围越大，故障类型的级别越高，检测顺序越靠后。例如，针对探测设备故障、城域平面内故障、骨干平面内故障、第一链路故障、以及第二链路故障等多种故障类型，骨干平面内故障相关的探测流覆盖范围最大，探测设备故障相关的探测流覆盖范围最小，可以设置探测设备故障的检测顺序为首位，依次为第一链路故障、城域平面内故障、第二链路故障、骨干平面内故障等。

具体地，服务器可以针对非首位的故障类型，确定由在前的故障检测而获得的故障探测流，从指定探测数据中剔除掉故障探测流，并基于剔除故障探测流后的探测数据进行所针对的故障类型的故障检测。

在一些实施例中，服务器可以针对每一个非首位的故障类型，均在故障检测后对确定的故障探测流进行剔除，后续在对下一个故障类型进行故障检测时，是基于剔除了故障探测流之后的探测数据进行故障检测的。

上述实施例中，服务器可以针对非首位的故障类型，确定由在前的故障检测而获得的故障探测流，从指定探测数据中剔除掉故障探测流，并基于剔除故障探测流后的探测数据进行所针对的故障类型的故障检测。从而提升故障检测的精度。

在一个实施例中，广域网络为三维立体网络，由部署于不同城市的不同园区内的网络节点、各城市分别对应的城域多平面、以及骨干多平面互联构成；故障类型包括探测设备故障、城域平面内故障、骨干平面内故障、第一链路故障、以及第二链路故障；其中，第一链路为园区内网络节点与城域平面内的网络节点之间的网络链路，第二链路为城域平面内的网络节点与骨干平面内的网络节点之间的网络链路。

城域多平面是指包括多个城域平面的城域网络，骨干多平面是指包括多个骨干平面的骨干网络，城域平面内可以包括有多个网络节点，骨干平面内也可以包括多个网络节点。

本申请实施例中，广域网络可以是DCI网络。DCI网络是一种基于分Set（单元化）、多平面设计的三维立体网络，旨在实现高容量和高质量的网络服务。DCI网络具体可以包括CDN（Content Delivery Network、内容分发网络）节点、网络节点以及核心设备等，承载数万G（千兆字节）流量信息交互的一张全球大型广域网络，流量信息可以包括出口宽带、内网宽带等。

请继续参考图4，图4为DCI网络的新一代网络架构图，结合DCI网络城域多平面、骨干多平面的特点，DCI网络可以包括用于建立城市A的园区间通信的A市城域平面-1、A市城域平面-2、A市城域平面-3、A市城域平面-4，DCI网络还可以包括建立不同城市的园区间通信的骨干平面-1、骨干平面-2、骨干平面-3以及骨干平面-4，DCI网络可以包括用于建立城市B的园区间通信的B市城域平面-1、B市城域平面-2、B市城域平面-3、B市城域平面-4。其中，各城域平面和骨干平面上存在有网络节点，各网络节点之间相互网络连接，从而实现同一城市、不同城市园区间的信息交互，图4中，A市城域平面-1和B市城域平面-1均可以包括多个网络节点，骨干平面-1可以包括多个网络节点。

上述实施例中，通过将广域网络中的故障切分为探测设备故障、城域平面内故障、骨干平面内故障、第一链路故障、以及第二链路故障，使得将广域网络进行了分解，将其切分为更小的单元进行针对性的检测，从而便于快速发现故障所在的节点和链路，可以提高故障隔离和定位的速度和精确度，减少网络故障对业务的影响。

在一个实施例中，针对任一级别的故障类型，从网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于指定探测数据进行故障检测，包括：根据与各网络探测数据分别对应的路径相关信息，从网络探测数据中筛选与探测设备故障相关的第一探测数据、与第一链路故障相关的第二探测数据、与城域平面内故障相关的第三探测数据、与第二链路故障相关的第四探测数据、以及与骨干平面内故障相关的第五探测数据；基于第一探测数据进行故障检测，定位出存在故障的探测设备，并确定由存在故障的探测设备而生成的第一故障探测流；从第二探测数据中剔除第一故障探测流；基于剔除第一故障探测流后的第二探测数据进行故障检测，定位出存在故障的第一链路，并确定与存在故障的第一链路相关的第二故障探测流；从第三探测数据中剔除第一故障探测流和第二故障探测流；基于剔除故障探测流后的第三探测数据进行故障检测，定位出存在故障的城域平面，并确定与存在故障的城域平面相关的第三故障探测流；从第四探测数据中剔除第一故障探测流和第二故障探测流；基于剔除故障探测流后的第四探测数据进行故障检测，定位出存在故障的第二链路，并确定与存在故障的第二链路相关的第四故障探测流；从第五探测数据中剔除第一故障探测流、第二故障探测流、以及第四故障探测流；基于剔除故障探测流后的第五探测数据进行故障检测，定位出存在故障的骨干平面，并确定与存在故障的骨干平面相关的第五故障探测流；基于第一故障探测流、第二故障探测流、第三故障探测流、第四故障探测流、以及第五故障探测流，确定检测结果。

其中，第一探测数据是与探测设备故障相关的数据，本申请中，在城域内探测流和跨城域探测流中，涉及到的与探测设备相关的探测流对应的探测数据均可以作为第一探测数据。

第二探测数据是与第一链路故障相关的数据，如针对广域网络进行网络探测过程中，在城域内探测流和跨城域探测流中，涉及到从园区传输至城域平面的探测流对应的探测数据均可以作为第二探测数据。

第三探测数据是与城域平面内故障相关的数据，针对广域网络进行网络探测过程中，在城域内探测流中，涉及到经过城域平面的探测流对应的探测数据均可以作为第三探测数据。

第四探测数据是与第二链路故障相关的数据，针对广域网络进行网络探测过程中，在跨城域探测流中，涉及到从城域平面传输至骨干平面的探测流对应的探测数据均可以作为第四探测数据。

第五探测数据是与骨干平面内故障相关的数据，针对广域网络进行网络探测过程中，在跨城域探测流中，涉及到经过骨干平面的探测流对应的探测数据均可以作为第五探测数据。

参考图5，图5为一个实施例中网络故障检测方法涉及到的部分探测流，可以包括园区A探测机与园区B探测机之间的探测流1、探测流2、园区A与园区C之间的探测流3、探测流4、园区C与园区D之间的探测流5、探测流6，园区A和园区B可以为同一城市的两个不同的园区，园区C和园区D可以为同一城市的两个不同的园区，对于同一城市的不同的园区，可以通过城域平面进行通信，对于不同城市的园区，则还需要通过骨干平面进行通信。

在一些实施例中，服务器可以基于路径相关信息，从网络探测数据确定出与各故障类型匹配的第一探测数据、第二探测数据、第三探测数据、第四探测数据以及第五探测数据。进一步地，服务器可以基于节点信息，从第一探测数据中确定出与每一个探测设备分别相关的探测流，从第二探测数据中确定出与每一个指定园区至指定城域平面分别相关的探测流，从第三探测数据中确定出与每一个指定城域平面分别相关的探测流，从第四探测数据中确定出与每一个指定城域平面至指定骨干平面分别相关的探测流，从第三探测数据中确定出与每一个指定骨干平面分别相关的探测流，从而可以针对性的对指定的设备、平面等进行故障分析，提升故障分析的效率与准确性。

在一些实施例中，服务器在针对DCI网络中的任意一个探测设备进行故障检测时，可以基于该探测设备的节点信息，从第一探测数据中，确定与该探测设备相关的城域内探测流和跨城域探测流，并针对与该探测设备相关的城域内探测流和跨城域探测流进行丢包率分析，若确定均产生丢包现象，则判定该探测设备故障，并确定由该故障探测设备生成的第一故障探测流。在进行第一链路故障检测前，会从第二探测数据中剔除导致已知故障的第一故障探测流，针对剔除导致已知故障的第二探测数据进行故障检测。进一步地，服务器还可以基于节点信息，从第二探测数据中，确定与某个指定园区、指定城域平面相关的城域内探测流和跨城域探测流，并对与该指定园区、指定城域平面相关的城域内探测流和跨城域探测流进行丢包率分析，若确定经过该指定园区和指定城域平面的探测流均产生丢包现象，则判定该指定园区到指定城域平面存在故障，确定与该园区到指定城域平面相关的第二故障探测流。

在进行城域平面内故障和第二链路故障检测前，会分别从第三探测数据中剔除导致已知故障的第一故障探测流、第二故障探测流，以及从第四探测数据中剔除导致已知故障的第一故障探测流、第二故障探测流。并对剔除导致已知故障的第三探测数据、第四探测数据分别进行故障检测。

针对城域平面内故障的检测，服务器还可以基于节点信息，从第三探测数据中，确定与某个指定城域平面相关的城域内探测流，并对与该指定城域平面相关的城域内探测流进行丢包率分析，若确定经过该指定城域平面的探测流均产生丢包现象，则判定该城域平面故障，确定与该城域平面相关的第三故障探测流。

针对第二链路故障，服务器还可以基于节点信息，从第四探测数据中，确定与某个指定城域平面、指定骨干平面相关的跨城域探测流，并对与该指定城域平面、指定骨干平面相关的跨城域探测流进行丢包率分析，若确定经过该指定城域平面到该指定骨干平面的探测流均产生丢包现象，则判定该指定城域平面到该指定骨干平面对应的第二链路故障，确定与存在故障的第二链路相关的第四故障探测流。

在进行骨干平面故障检测前，会从第五探测数据中剔除导致已知故障的第一故障探测流、第二故障探测流以及第四故障探测流。针对剔除导致已知故障的第五探测数据进行故障检测，服务器还可以基于节点信息，从第五探测数据中，确定与某个指定骨干平面相关的跨城域探测流，并对与该指定骨干平面相关的跨城域探测流进行丢包率分析，若确定经过该指定骨干平面的探测流均产生丢包现象，则判定该指定骨干平面存在故障，确定与该指定骨干平面相关的第五故障探测流。

最后基于第一故障探测流、第二故障探测流、第三故障探测流、第四故障探测流、以及第五故障探测流，确定检测结果。

上述实施例中，服务器在进行故障检测时，针对每类故障类型，获取对应的指定探测数据，并按照检测顺序，依次剔除掉存在故障的故障探测流，可以快速发现故障所在的节点和链路，提高故障隔离和定位的速度和精确度，减少网络故障对业务的影响。

在一个实施例中，探测设备故障、第一链路故障、以及第二链路故障通过第一处理队列依次执行；城域平面内故障通过第二处理队列执行，骨干平面内故障通过第三处理队列执行。

其中，第一处理队列、第二处理队列以及第三处理队列为设定的分别对各故障类型展开故障检测的处理队列。第一处理队列可以针对探测设备故障、第一链路故障、以及第二链路故障展开故障检测，城域平面内故障的故障检测可以通过第二处理队列执行，骨干平面内的故障检测可以通过第三处理队列执行。具体地，服务器可以针对不同的故障类型进行分类处理，通过三个处理队列，第一处理队列、第二处理队列以及第三处理队列并行分析网络中可能存在的故障，通过这种流水线的处理方式，可以有效提高探测流的处理效率，使其能够在1秒内完成数千条探测数据的分析处理。

上述实施例中，通过第一处理队列、第二处理队列以及第三处理队列分别对各故障类型展开故障检测的处理队列，能够达到提升网络故障的检测精度。

在一个实施例中，网络检测结果为任一检测周期的网络检测结果；网络故障检测方法还包括：基于各检测周期的网络检测结果确定各检测周期的故障告警信息；根据多个检测周期的故障告警信息确定告警级别，并根据告警级别进行相应的故障告警处理。

故障告警信息是在各检测周期内，针对所定位出的广域网络中存在故障的节点、链路等产生的告警信息。例如，故障告警信息可以包括针对探测设备故障、城域平面内故障、骨干平面内故障、第一链路故障、以及第二链路故障等分别产生的故障告警信息。

图6为一个实施例中示意的故障告警信息，通过对各园区探测流数据的分析，能够快速有效地识别上述5类故障，同时实时定位故障产生的位置，并推送如图6所示的告警信息给运维人员进行处理。图6示意的故障告警信息中，包含了产生故障的详细信息，如立体监测告警指示的告警类型、故障产生时间，即告警首次出现时间、最近告警时间，即告警最近出现时间、告警校验情况以及故障影响情况等。例如，告警类型为骨干平面故障。每一类告警类型对应有相应的告警详细内容：平面信息和设备信息。告警校验情况是将告警数据与原始探测数据进行校验，即将原始探测数据与告警数据进行比较，对告警数据进行校验，验证告警数据的真实性，通过采用探测流原始数据，即原始探测数据进行校验，从而验证告警判断逻辑，可以覆盖城域、正交以及骨干等类型的故障。故障影响情况可以是将原始探测数据与同时段的业务探测数据进行比较，确定原始探测数据出现的丢包现象是否对业务探测数据有影响，如业务探测数据是否也存在丢包现象，从而可以提供参考，在有影响的时候进行处理，可以覆盖城域以及骨干等类型的故障。进一步地，告警信息中还提供业务指标的相关比较，如显示当前故障是否会影响线上业务、提供探测流详情链接，通过探测流详情链接，可以方便跳转。

告警级别是用于标明告警强弱程度的分类单位。告警级别可以为预先设定的级别，在设定告警级别时，可以依据告警信息中某种类型的故障产生告警的次数、故障所处于广域网络中位置等进行设置，具体的告警级别的设定可以结合实际的故障告警情况进行设定，通过设定不同的告警级别，可以方便运营人员采取与告警级别匹配的故障修复方式针对故障进行修复，能够有效缩短网络故障的处理周期，提高广域网络的运营效率。

在具体实施时，服务器可以设定两个告警级别，即第一告警级别、第二告警级别，第一告警级别的告警强度高于第二告警级别的告警强度。服务器可以对各检测周期的故障告警信息进行综合分析，得到总的故障告警汇总结果，并基于总的故障告警汇总结果确定出告警级别。服务器针对确定出的告警级别，采取与告警级别匹配的故障告警方式展开故障告警处理，如对于第一告警级别，可以为直接关闭故障所在位置的节点、切断故障所处的链路等，针对第二告警级别，可以为通过邮件、短信等方式发送提示信息。

需要说明的是，服务器还可设定更多的告警级别，比如3个或4个等，本申请实施例对此不作限定。

请参考图7，图7为一个实施例中故障告警信息展示图，告警信息展示图中包括了从A地到B地的探测数据中检测出了的故障类型，图7中的故障类型为骨干平面故障，涉及到的骨干平面可以为B2-B-04平面、B2-B-03平面。对于骨干平面故障，还包括了骨干平面故障涉及到的骨干平面信息，如在骨干平面上涉及到的设备信息以及故障持续时间，还包括有故障发生的时间，如时间1、时间3，以及告警时间，如时间2、时间4等信息，还包括有故障类型的级别。图7中共涉及到两个级别，即二级告警和一级告警。针对骨干平面故障，还记录有是否触发隔离、告警校验是否成功、是否恢复校验成功、业务探测是否正常、故障是否恢复等多种类型的信息。

上述实施例中，服务器通过获取各检测周期的网络检测结果，从每一个检测周期的网络检测结果中提取得到各检测周期的故障告警信息，并综合每一个检测周期的故障告警信息确定告警级别，根据告警级别进行相应的故障告警处理，可以提升网络故障判定的可靠性。

在一个实施例中，根据多个检测周期的故障告警信息确定告警级别，包括：基于各检测周期的故障告警信息进行故障定位，得到故障源；对多个检测周期中的相同故障源进行告警次数统计，并根据统计情况确定告警级别。

其中，故障源是发生故障的源头，即故障所在位置。在广域网络中，故障源具体可以包括发生故障的探测设备、发生故障的某一城域平面、发生故障的第一链路、发生故障的第二链路、以及发生故障的某一骨干平面等。

具体地，服务器可以基于各检测周期的故障告警信息进行故障定位，得到故障源，对多个检测周期中的相同故障源进行告警次数统计，并根据统计情况确定告警级别。

在具体实现时，告警级别可以是依据各类型的告警出现的次数设定的，如可以设定当同一类型的告警的次数大于设定的告警次数阈值时，告警级别为第一级别的告警；当同一类型的告警的次数小于等于设定的告警次数阈值时，告警级别为第二级别的告警，服务器可以统计各检测周期的故障告警信息，并对各故障告警信息中，每一类故障源导致告警的告警数量进行统计，获得统计结果，服务器可以进一步将获得的统计结果与设定的告警次数阈值进行比较，从而确定出告警级别。

上述实施例中，服务器通过根据各检测周期的故障告警信息进行故障定位，得到故障源，结合故障源进行告警次数统计，从而根据统计情况确定告警级别。可以提升网络故障判定的可靠性。

在一个实施例中，对多个检测周期中的相同故障源进行告警次数统计，并根据统计情况确定告警级别，包括：若在连续的第一预设数量个检测周期中均存在相同的故障源，则触发一级告警；若在第二预设数量个检测周期内，相同的故障源的出现次数达到第三预设数量，则触发二级告警；其中，第二预设数量大于第三预设数量。

其中，第一预设数量和第二预设数量可以相同，也可以不同。

需要说明的是，通过告警判断能力，虽然已经能够得到每个检测周期中广域网络的故障情况，但是考虑到网络中可能存在的瞬时突发流量以及网络抖动等现象，需要对每个检测周期单次故障进行进一步分析和处理以提升故障判定的可靠性。

具体地，服务器在收到每个检测周期的单次告警后，我们会根据缓存中的配置对单个故障源的单次告警进行累加，并进行二次故障诊断。配置规则如下：

（1）一级告警：连续N个周期产生某个单次告警；N为大于等于1的正整数；

（2）二级告警：在M个周期内，出现超过N次（M>N）单次告警。

例如，N可以设置为3，若在连续的3个检测周期内，探测设备A均发生了故障，则可以触发一级告警；又如，M可以设置为6，若在连续的6个检测周期内城域平面与骨干平面之间的链路1发生了4次故障，则可以触发二级告警。

上述实施例中，服务器通过在预设数量各检测周期内，对故障源的统计情况进行分析，可以准确的确定出告警级别，提升告警的可靠性。

本申请还提供一种应用场景，该应用场景应用上述的网络故障检测方法。具体地，该网络故障检测方法在该应用场景的应用如下：

如图8所示，为本申请提供的网络故障检测方法在进行网络故障检测时的整体架构图，该方法主要分为网络故障告警判断和告警处理两个部分：其中告警判断部分主要针对园区内以及园区间的探测数据进行分析从而定位故障所在位置；告警处理部分主要针对初步告警判断进行进一步的累积计数和分析，最终产生故障判断告警。下面可以分别针对网络故障检测方法的这两个部分进行详细介绍：

针对告警判断部分，为了降低网络探测数据的处理量，在订阅网络探测数据时，可以只关注有丢包现象的增量探测数据，增量探测数据为存在丢包现象的探测数据。在进行丢包率修正时，可以获取探测机告警集合展开，获得修正后的增量探测数据，其中，增量探测数据可以携带有时间、丢包率以及探测键值等信息，其中，探测键值可以与增量探测数据所对应的故障类型匹配。需要补充的是，目前为了提升探测的精度，园区间会安排一对探测机进行双活探测，即每个园区分别设置两个探测机，如园区A设置两个源探测机，源探测机1、源探测机2，园区B设置两个目的探测机，目的探测机1和目的探测机2，当园区A向园区B发送探测流时，可以包括园区A设置的源探测机1向园区B设置的目的探测机1和目的探测机2分别发送探测流，还可以包括园区A设置的源探测机2向园区B设置的目的探测机1和目的探测机2分别发送探测流，因此，当园区A向园区B发送探测流时，可以存在4条探测流，以避免探测机出现故障而导致的误判问题。因此，当源/目的中的一对探测机出现探测结果不一致时，需要针对探测结果进行修正，避免单台探测机异常而对整个探测结果造成影响。综上所述，在接收到增量探测数据的第一步就是结合探测机告警集合针对增量探测数据进行丢包率修正。在进行修正时，如目的探测机1异常时，可以将丢包率修正为目的探测机2的数值，在源探测机2以及目的探测机1均出现异常时，可以将丢包率修正为源探测机1至目的探测机2的数值。

接着，由于上报的增量探测数据可能来自不同的探测园区，考虑到上报延迟、网络抖动等各种因素，订阅的增量探测数据可能会出现乱序。为了解决这个问题，可以将修正后的增量探测数据按时间戳进行拆分，之后放入时间处理队列中。如图8中，时间处理队列可以包括T0-T4等多个时间点。在此基础上，针对每个周期的增量探测数据设置最长延迟等待时间，如上述实施例中设置的最长延迟等待时间为17s（秒），如果对应周期的数据超过该时间才被消费到，则会被直接丢弃。其中，最长延迟等待时间是结合网络上报数据延迟7s、解决数据乱序问题等待时长2s以及一级告警连续判断周期8s的和确定的。当某个周期的增量探测数据接收窗口关闭后，即时间超过阈值，则获取T_X时间的增量探测数据，T_X可以指预设周期，并基于每个预设周期的增量探测数据与对应周期的探测流集合，就能得到对应周期的全量探测流，即网络探测数据。其中，探测流集合中也携带了探测键值以及丢包率等信息。

目前，共会处理5种不同类型的告警，每种告警的判定逻辑如下：（1）园区探测机故障：在某个周期中，与某个探测机相关的城域内探测流和跨城域探测流均产生丢包现象，则判定该园区探测机故障；（2）园区到城域平面故障：在某个周期中，针对现有的探测机故障，剔除导致已知故障的探测流，经过某个园区和指定城域平面的探测流均产生丢包现象，则判定该园区到指定城域平面故障；（3）城域平面故障：在某个周期中，针对现有的探测机故障和园区到城域平面故障，剔除导致已知故障的探测流，经过某城域平面的探测流均产生丢包现象，则判定该城域平面故障；（4）正交链路故障：在某个周期中，针对现有的探测机故障和园区到城域平面故障，剔除导致已知故障的探测流，经过某城域平面到指定骨干平面的探测流均产生丢包现象，则判定该城域平面到特定骨干平面的正交链路故障；（5）骨干平面故障：在某个周期中，针对现有的探测机故障、园区到城域平面故障以及正交链路故障，剔除导致已知故障的探测流，经过某骨干平面的探测流均产生丢包现象，则判定该骨干平面故障。

针对每个周期的全量探测流，由于探测数据较多，为提高处理效率，可以针对探测流进行分类处理，通过三个处理队列，即三级告警判断队列：主队列、城域故障判断队列以及骨干故障判断队列并行分析网络中可能存在的故障。其中，主队列、城域故障判断队列以及骨干故障判断队列在进行故障检测时，会按照各级探测键值取探测流，如针对园区A到园区B的城域告警，基于探测键值，可以获得探测流A、探测流B以及探测流C展开故障检测。主队列会进行各个周期的探测机故障、园区到城域平面故障以及正交链路故障的判断；主队列将某个周期的探测机故障以及园区到城域平面故障相关探测流剔除后，会将该周期的探测数据发送给城域故障判断队列。该队列专职进行城域平面故障的判定。与此同时，主队列在进行完正交链路的故障判定并且完成故障探测流剔除后，会再将该周期的探测数据发送给骨干故障判断队列进行判定。通过这种流水线的处理方式，可以有效提高探测流的处理效率，使其能够在1秒内完成数千条探测数据的分析处理。

在此基础上，在告警处理之前，针对每一类告警缓存对应的探测流异常情况，即告警键值缓存，如针对园区A到园区B的告警键值缓存，可以为：探测键值：探测流A、探测键值：探测流B以及探测键值：探测流C。例如，某个园区产生了探测机故障，那么呈现出来的探测流情况就是所有和该园区相关的探测流均出现丢包现象。而每个周期的探测流详情我们可以提前计算得到，通过缓存的方式可以有效减少单个周期的告警判断时间，提高处理效率。综上所述，通过告警判断模块能够得到每个探测周期DCI网络的故障情况。

在告警处理部分，在收到每个周期的单次探测告警后，可以进行各类型/级别的告警判断缓存，如针对园区A-园区B的城域告警，在告警判断缓存中记录连续告警次数、间隔告警次数以及告警恢复次数等信息，服务器可以根据缓存中的配置对单次告警进行累加，并进行二次故障诊断，目前设置了两种不同的故障生成规则：（1）一级告警：连续N个周期产生某个单次告警；（2）二级告警：在M个周期内，出现超过N次（M>N）单次告警。当单次告警累计触发一级告警或者二级告警后，服务器会将故障告警分别转发至立体监测告警信息处以及网络自愈流程，如可以基于存储实例共享至立体监测告警信息处，以及日志汇处，其中，存储实例可以为CKAFKA（Cloud Kafka，云上的消息队列系统）存储实例，其为开源的消息队列系统。告警处理模块具备告警抑制、告警验证以及告警转存的能力，一方面可以减少冗余告警的重复推送，另一方面也提供了相关告警的查询以及展示入口，如生成工单，以及通过正式告警推送机器人文件/短信等。此外，目前的网络自愈流程支持运营人员根据相关告警进行自定义处理，通过自动化流程能够对网络故障进行快速响应。通过本申请提供的网络故障检测方法，能够有效缩短网络故障的处理周期，将之前动辄数十分钟的故障收敛时间降低至一分钟以内，大大提高了DCI网络的运营效率。与此同时，如图9所示，在近一段时间的运营中，该技术方案在每个统计周期内，如时间段1、时间段2…时间段7都能产生数十条告警，精确定位对应的网络故障，平均故障定位准确率达到95.8%。这些告警能够有效帮助运营人员及时发现网络中存在的异常情况，为DCI网络的稳定可靠保驾护航。

本申请提出的网络故障检测方法分解了整个网络，将其切分为更小的单元，各个切片拥有相互独立的运营和管理，同时又可以彼此通信和交流。采用本申请提供的网络故障检测方法，可以更好地进行链路的故障隔离和定位。在发生链路故障时，通过针对增量的探测数据进行分析，控制器可以快速发现故障所在的切片，并以切片为单位分析故障所在的节点和链路。这种方法可以大大降低网络的故障域，提高故障隔离和定位的速度和精确度，减少网络故障对业务的影响，具有非常重要的意义。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的网络故障检测方法的网络故障检测装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个网络故障检测装置实施例中的具体限定可以参见上文中对于网络故障检测方法的限定，在此不再赘述。

在一个实施例中，如图10所示，提供了一种网络故障检测装置1000，包括：数据获取模块1002、路径信息确定模块1004、故障检测模块1006和检测结果确定模块1008，其中：

数据获取模块1002，用于获取网络探测数据；网络探测数据通过按照指定的探测路径对广域网络进行网络探测而得到。

路径信息确定模块1004，用于确定与各网络探测数据分别对应的路径相关信息；路径相关信息指示了网络探测数据所来源的探测路径。

故障检测模块1006，用于针对任一级别的故障类型，从网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于指定探测数据进行故障检测。

检测结果确定模块1008，用于根据各级别故障类型分别对应的检测结果，确定网络检测结果。

在一个实施例中，数据获取模块1002，还用于获取按照指定的探测路径对广域网络进行网络探测得到的原始探测数据；提取原始探测数据中的增量探测数据；增量探测数据表征存在丢包现象；对增量探测数据进行去干扰调整，得到调整后的增量探测数据；基于调整后的增量探测数据、以及原始探测数据，确定用于进行故障检测的网络探测数据。

在一个实施例中，数据获取模块1002包括去干扰调整模块；去干扰调整模块，用于对增量探测数据进行丢包率修正，得到修正后的增量探测数据；将修正后的增量探测数据按照时序进行拆分，并将拆分后的数据放入时间处理队列；提取预设检测周期内时间处理队列中的数据，得到调整后的增量探测数据。

在一个实施例中，数据获取模块1002还包括丢包率修正模块；丢包率修正模块，用于针对任一探测路径，在与所针对的探测路径对应的原始探测数据中存在丢包情况不一致的情况下，对与所针对的探测路径对应的增量探测数据进行丢包率修正，得到修正后的增量探测数据。

在一个实施例中，故障检测模块1006，还用于针对任一级别的故障类型，确定与所针对的故障类型相关的路径类型；从网络探测数据中筛选出指定探测数据；指定探测数据所来源的探测路径的路径类型与所针对的故障类型相关；基于指定探测数据进行所针对的故障类型的故障检测。

在一个实施例中，不同级别的故障类型对应不同的检测顺序，若所针对的故障类型的检测顺序为非首位，则故障检测模块1006，还用于确定由在前的故障检测而获得的故障探测流；从指定探测数据中剔除掉故障探测流，并基于剔除故障探测流后的探测数据进行所针对的故障类型的故障检测。

在一个实施例中，广域网络为三维立体网络，由部署于不同城市的不同园区内的网络节点、各城市分别对应的城域多平面、以及骨干多平面互联构成；故障类型包括探测设备故障、城域平面内故障、骨干平面内故障、第一链路故障、以及第二链路故障；其中，第一链路为园区内网络节点与城域平面内的网络节点之间的网络链路，第二链路为城域平面内的网络节点与骨干平面内的网络节点之间的网络链路。

在一个实施例中，故障检测模块1006，还用于根据与各网络探测数据分别对应的路径相关信息，从网络探测数据中筛选与探测设备故障相关的第一探测数据、与第一链路故障相关的第二探测数据、与城域平面内故障相关的第三探测数据、与第二链路故障相关的第四探测数据、以及与骨干平面内故障相关的第五探测数据；基于第一探测数据进行故障检测，定位出存在故障的探测设备，并确定由存在故障的探测设备而生成的第一故障探测流；从第二探测数据中剔除第一故障探测流；基于剔除第一故障探测流后的第二探测数据进行故障检测，定位出存在故障的第一链路，并确定与存在故障的第一链路相关的第二故障探测流；从第三探测数据中剔除第一故障探测流和第二故障探测流；基于剔除故障探测流后的第三探测数据进行故障检测，定位出存在故障的城域平面，并确定与存在故障的城域平面相关的第三故障探测流；从第四探测数据中剔除第一故障探测流和第二故障探测流；基于剔除故障探测流后的第四探测数据进行故障检测，定位出存在故障的第二链路，并确定与存在故障的第二链路相关的第四故障探测流；从第五探测数据中剔除第一故障探测流、第二故障探测流、以及第四故障探测流；基于剔除故障探测流后的第五探测数据进行故障检测，定位出存在故障的骨干平面，并确定与存在故障的骨干平面相关的第五故障探测流；基于第一故障探测流、第二故障探测流、第三故障探测流、第四故障探测流、以及第五故障探测流，确定检测结果。

在一个实施例中，探测设备故障、第一链路故障、以及第二链路故障通过第一处理队列依次执行；城域平面内故障通过第二处理队列执行，骨干平面内故障通过第三处理队列执行。

在一个实施例中，网络故障检测装置还包括故障告警模块；故障告警模块，用于基于各检测周期的网络检测结果确定各检测周期的故障告警信息；根据多个检测周期的故障告警信息确定告警级别，并根据告警级别进行相应的故障告警处理。

在一个实施例中，故障告警模块，还用于基于各检测周期的故障告警信息进行故障定位，得到故障源；对多个检测周期中的相同故障源进行告警次数统计，并根据统计情况确定告警级别。

在一个实施例中，故障告警模块，还用于若在连续的第一预设数量个检测周期中均存在相同的故障源，则触发一级告警；若在第二预设数量个检测周期内，相同的故障源的出现次数达到第三预设数量，则触发二级告警；其中，第二预设数量大于第三预设数量。

上述网络故障检测装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器或终端，其内部结构图可以如图11所示。该计算机设备包括处理器、存储器、输入/输出接口(Input/Output，简称I/O）和通信接口。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储网络探测数据。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种网络故障检测方法。

本领域技术人员可以理解，图11中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要符合相关规定。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-OnlyMemory，ROM）、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器（ReRAM）、磁变存储器（Magnetoresistive Random Access Memory，MRAM）、铁电存储器（Ferroelectric RandomAccess Memory，FRAM）、相变存储器（Phase Change Memory，PCM）、石墨烯存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic RandomAccessMemory，DRAM）等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (16)

1.一种网络故障检测方法，其特征在于，所述方法包括：

获取网络探测数据；所述网络探测数据通过按照指定的探测路径对广域网络进行网络探测而得到；

确定与各所述网络探测数据分别对应的路径相关信息；所述路径相关信息指示了网络探测数据所来源的探测路径；

针对任一级别的故障类型，从所述网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于所述指定探测数据进行故障检测；

根据各级别故障类型分别对应的检测结果，确定网络检测结果。

2.根据权利要求1所述的方法，其特征在于，所述获取网络探测数据，包括：

获取按照指定的探测路径对广域网络进行网络探测得到的原始探测数据；

提取所述原始探测数据中的增量探测数据；所述增量探测数据表征存在丢包现象；

对所述增量探测数据进行去干扰调整，得到调整后的增量探测数据；

基于所述调整后的增量探测数据、以及所述原始探测数据，确定用于进行故障检测的网络探测数据。

3.根据权利要求2所述的方法，其特征在于，所述对所述增量探测数据进行去干扰调整，得到调整后的增量探测数据，包括：

对所述增量探测数据进行丢包率修正，得到修正后的增量探测数据；

将所述修正后的增量探测数据按照时序进行拆分，并将拆分后的数据放入时间处理队列；

提取预设检测周期内所述时间处理队列中的数据，得到调整后的增量探测数据。

4.根据权利要求3所述的方法，其特征在于，所述对所述增量探测数据进行丢包率修正，得到修正后的增量探测数据，包括：

针对任一探测路径，在与所针对的探测路径对应的原始探测数据中存在丢包情况不一致的情况下，对与所针对的探测路径对应的增量探测数据进行丢包率修正，得到修正后的增量探测数据。

5.根据权利要求1所述的方法，其特征在于，所述针对任一级别的故障类型，从所述网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于所述指定探测数据进行故障检测，包括：

针对任一级别的故障类型，确定与所针对的故障类型相关的路径类型；

从所述网络探测数据中筛选出指定探测数据；所述指定探测数据所来源的探测路径的路径类型与所针对的故障类型相关；

基于所述指定探测数据进行所针对的故障类型的故障检测。

6.根据权利要求5所述的方法，其特征在于，不同级别的故障类型对应不同的检测顺序，若所针对的故障类型的检测顺序为非首位，则所述基于所述指定探测数据进行所针对的故障类型的故障检测，包括：

确定由在前的故障检测而获得的故障探测流；

从所述指定探测数据中剔除掉所述故障探测流，并基于剔除故障探测流后的探测数据进行所针对的故障类型的故障检测。

7.根据权利要求1所述的方法，其特征在于，所述广域网络为三维立体网络，由部署于不同城市的不同园区内的网络节点、各城市分别对应的城域多平面、以及骨干多平面互联构成；所述故障类型包括探测设备故障、城域平面内故障、骨干平面内故障、第一链路故障、以及第二链路故障；其中，第一链路为园区内网络节点与城域平面内的网络节点之间的网络链路，第二链路为城域平面内的网络节点与骨干平面内的网络节点之间的网络链路。

8.根据权利要求7所述的方法，其特征在于，所述针对任一级别的故障类型，从所述网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于所述指定探测数据进行故障检测，包括：

根据与各所述网络探测数据分别对应的路径相关信息，从所述网络探测数据中筛选与探测设备故障相关的第一探测数据、与第一链路故障相关的第二探测数据、与城域平面内故障相关的第三探测数据、与第二链路故障相关的第四探测数据、以及与骨干平面内故障相关的第五探测数据；

基于所述第一探测数据进行故障检测，定位出存在故障的探测设备，并确定由所述存在故障的探测设备而生成的第一故障探测流；

从所述第二探测数据中剔除所述第一故障探测流；

基于剔除第一故障探测流后的第二探测数据进行故障检测，定位出存在故障的第一链路，并确定与所述存在故障的第一链路相关的第二故障探测流；

从所述第三探测数据中剔除所述第一故障探测流和所述第二故障探测流；

基于剔除故障探测流后的第三探测数据进行故障检测，定位出存在故障的城域平面，并确定与所述存在故障的城域平面相关的第三故障探测流；

从所述第四探测数据中剔除所述第一故障探测流和所述第二故障探测流；

基于剔除故障探测流后的第四探测数据进行故障检测，定位出存在故障的第二链路，并确定与所述存在故障的第二链路相关的第四故障探测流；

从所述第五探测数据中剔除所述第一故障探测流、所述第二故障探测流、以及所述第四故障探测流；

基于剔除故障探测流后的第五探测数据进行故障检测，定位出存在故障的骨干平面，并确定与所述存在故障的骨干平面相关的第五故障探测流；

基于所述第一故障探测流、所述第二故障探测流、所述第三故障探测流、所述第四故障探测流、以及所述第五故障探测流，确定检测结果。

9.根据权利要求8所述的方法，其特征在于，所述探测设备故障、第一链路故障、以及第二链路故障通过第一处理队列依次执行；所述城域平面内故障通过第二处理队列执行，所述骨干平面内故障通过第三处理队列执行。

10.根据权利要求1至9中任一项所述的方法，其特征在于，所述网络检测结果为任一检测周期的网络检测结果；所述方法还包括：

基于各检测周期的网络检测结果确定各检测周期的故障告警信息；

根据多个检测周期的故障告警信息确定告警级别，并根据所述告警级别进行相应的故障告警处理。

11.根据权利要求10所述的方法，其特征在于，所述根据多个检测周期的故障告警信息确定告警级别，包括：

基于各检测周期的故障告警信息进行故障定位，得到故障源；

对多个检测周期中的相同故障源进行告警次数统计，并根据统计情况确定告警级别。

12.根据权利要求11所述的方法，其特征在于，所述对多个检测周期中的相同故障源进行告警次数统计，并根据统计情况确定告警级别，包括：

若在连续的第一预设数量个检测周期中均存在相同的故障源，则触发一级告警；

若在第二预设数量个检测周期内，相同的故障源的出现次数达到第三预设数量，则触发二级告警；其中，所述第二预设数量大于所述第三预设数量。

13.一种网络故障检测装置，其特征在于，所述装置包括：

数据获取模块，用于获取网络探测数据；所述网络探测数据通过按照指定的探测路径对广域网络进行网络探测而得到；

路径信息确定模块，用于确定与各所述网络探测数据分别对应的路径相关信息；所述路径相关信息指示了网络探测数据所来源的探测路径；

故障检测模块，用于针对任一级别的故障类型，从所述网络探测数据中筛选路径相关信息与所针对的故障类型匹配的指定探测数据，并基于所述指定探测数据进行故障检测；

检测结果确定模块，用于根据各级别故障类型分别对应的检测结果，确定网络检测结果。

14.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至12中任一项所述的方法的步骤。

15.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至12中任一项所述的方法的步骤。

16.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至12中任一项所述的方法的步骤。