CN112073234A - 一种故障检测方法、装置、系统、设备及存储介质 - Google Patents
一种故障检测方法、装置、系统、设备及存储介质 Download PDFInfo
- Publication number
- CN112073234A CN112073234A CN202010909180.0A CN202010909180A CN112073234A CN 112073234 A CN112073234 A CN 112073234A CN 202010909180 A CN202010909180 A CN 202010909180A CN 112073234 A CN112073234 A CN 112073234A
- Authority
- CN
- China
- Prior art keywords
- request packet
- gateway server
- server
- gateway
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 333
- 238000000034 method Methods 0.000 claims abstract description 53
- 239000000523 sample Substances 0.000 claims description 98
- 238000013507 mapping Methods 0.000 claims description 46
- 230000005540 biological transmission Effects 0.000 claims description 29
- 238000004590 computer program Methods 0.000 claims description 13
- 230000002159 abnormal effect Effects 0.000 claims description 10
- 230000004044 response Effects 0.000 claims description 3
- 238000004043 dyeing Methods 0.000 description 25
- 238000012545 processing Methods 0.000 description 20
- 230000008569 process Effects 0.000 description 19
- 238000010586 diagram Methods 0.000 description 18
- 238000004891 communication Methods 0.000 description 9
- 238000004458 analytical method Methods 0.000 description 8
- 238000012360 testing method Methods 0.000 description 7
- 238000012423 maintenance Methods 0.000 description 6
- 239000003795 chemical substances by application Substances 0.000 description 5
- 238000012544 monitoring process Methods 0.000 description 5
- 238000007405 data analysis Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 239000003814 drug Substances 0.000 description 3
- 238000005538 encapsulation Methods 0.000 description 3
- 241001137251 Corvidae Species 0.000 description 2
- 238000004040 coloring Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 238000010186 staining Methods 0.000 description 2
- 101150014929 TPS2 gene Proteins 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 201000010099 disease Diseases 0.000 description 1
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000007850 fluorescent dye Substances 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000000968 medical method and process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012946 outsourcing Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 244000052769 pathogen Species 0.000 description 1
- 230000001717 pathogenic effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000010223 real-time analysis Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请实施例公开了云技术领域中的一种故障检测方法、装置、系统、设备及存储介质，其中该方法包括：在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息，所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息，所述网络设备包括客户端、网关服务器和业务服务器中的至少一个；将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息；根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。该方法能够基于探测请求包的路由链路路径，实现复杂网络环境中的网关故障检测及定位。
Description
技术领域
本申请涉及通信技术领域，尤其涉及一种故障检测方法、装置、系统、设备及存储介质。
背景技术
网关作为外部业务请求进入内部业务网络系统的第一道关口，其在互联网业务的持续接入中起着至关重要的作用。随着互联网业务的迅速发展和广泛普及，目前经过网关的业务流量通常是巨大的(如超过10T)，在这种情况下，任何微小的、短暂的质量波动都可能给互联网业务带来难以估量的影响。
网关作为外部业务请求到达内部业务服务器的必经之路，其属于最基础的网络设施，通常具有以下特点：1)业务敏感度高，对于较为敏感的互联网业务来说，1-2分钟的故障都是不可接受的，必须做到秒级发现和处理故障；2)故障定位困难，通常情况下，网关系统中任何一个环节出现问题都可能对整个网络链路产生影响，但是由于网络环境以及网关系统架构的复杂性，检测到网络链路受到影响后往往难以准确锁定出现问题的环节。
可见，如何快速准确地定位网关系统中的故障，已成为目前亟待解决的问题。
发明内容
本申请实施例提供了一种故障检测方法、装置、系统、设备及存储介质，能够快速准确地检测网关服务器是否存在故障。
有鉴于此，本申请第一方面提供了一种故障检测方法，所述方法包括：
在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息；所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息；所述网络设备包括客户端、网关服务器和业务服务器中的至少一个；
将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息；
根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。
本申请第二方面提供了一种故障检测装置，所述装置包括：
信息获取模块，用于在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息；所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息；所述网络设备包括客户端、网关服务器和业务服务器中的至少一个；
所述信息获取模块，还用于将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息；
故障检测模块，用于根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。
本申请第三方面提供了一种故障检测系统，所述系统包括：客户端、网关服务器和故障检测服务器；
所述客户端，用于根据其对于探测请求包的发包操作和收包操作生成打点信息，并将所述打点信息上报至所述故障检测服务器；
所述网关服务器，用于根据其对于所述探测请求包的发包操作和收包操作生成打点信息，并将所述打点信息上报至所述故障检测服务器；
所述故障检测服务器，用于执行如上述第一方面所述的故障检测方法。
本申请第四方面提供了一种设备，所述设备包括处理器以及存储器：
所述存储器用于存储计算机程序；
所述处理器用于根据所述计算机程序，执行如上述第一方面所述的故障检测方法的步骤。
本申请第五方面提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行上述第一方面所述的故障检测方法的步骤。
本申请第六方面提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第一方面所述的故障检测方法的步骤。
从以上技术方案可以看出，本申请实施例具有以下优点：
本申请实施例提供了一种故障检测方法，该方法借鉴医学上利用同位素或荧光剂染色定位病因的方式，对互联网中经过网络设备的探测请求包进行全链路染色打点，即利用客户端、网关服务器和业务服务器中的至少一个，根据其对于探测请求包进行的操作生成探测请求包的打点信息，进而，基于在故障检测周期内获取到的探测请求包的打点信息，对网络设备进行网关故障检测，以准确检测网络设备是否存在故障，并在检测到存在故障的情况下定位故障位置和故障原因。如此，基于探测请求包的传输链路路径，实现复杂网络环境中的网关故障检测及定位。
附图说明
图1为本申请实施例提供的故障检测系统的工作架构示意图；
图2为本申请实施例提供的记录打点信息的原理示意图；
图3为本申请实施例提供的故障检测方法的流程示意图；
图4为本申请实施例提供的示例性的网络架构示意图；
图5为本申请实施例提供的网关服务器中主转发程序的转发流程示意图；
图6为本申请实施例提供的控制客户端与业务服务器通信的原理示意图；
图7为本申请实施例提供的染色系统的工作原理示意图；
图8为本申请实施例提供的日志转发程序和日志分析程序的原理示意图；
图9为本申请实施例提供的一种网关集群的工作性能曲线图；
图10为本申请实施例提供的另一种网关集群的工作性能曲线图；
图11为本申请实施例提供的第一种故障检测装置的结构示意图；
图12为本申请实施例提供的第二种故障检测装置的结构示意图；
图13为本申请实施例提供的第三种故障检测装置的结构示意图；
图14为本申请实施例提供的第四种故障检测装置的结构示意图；
图15为本申请实施例提供的服务器的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
针对如何快速准确地对网关服务器进行故障检测这一问题，本申请实施例提供了一种故障检测方法，该方法借鉴医学上利用同位素或荧光剂染色定位病因的方式，对互联网中经过网络设备的探测请求包进行全链路染色打点，即利用客户端、网关服务器和业务服务器中的至少一个，根据其对于探测请求包进行的操作生成探测请求包的打点信息，进而，基于在故障检测周期内获取到的探测请求包的打点信息，对网络设备进行网关故障检测，以准确检测网络设备是否存在故障，并在检测到存在故障的情况下定位故障位置和故障原因。如此，基于探测请求包的传输链路路径，实现复杂网络环境中的网关故障检测及定位。
需要说明的是，本申请实施例提供的故障检测方法通常应用于具备数据处理能力的服务器，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，本申请在此不做限制。
为了便于理解本申请实施例提供的故障检测方法，下面先结合网关服务器的工作架构，对本申请实施例提供的故障检测方法所应用的故障检测系统进行介绍。
参见图1，图1为本申请实施例提供的故障检测系统的工作架构示意图。如图1所示，本申请实施例提供的故障检测系统包括客户端110、网关服务器120和故障检测服务器130，该故障检测系统通常部署在互联网通信架构中，该互联网通信架构还包括业务服务器140、外网交换机150和内网交换机160。
其中，客户端110用于生成第一请求包，并通过网关服务器120向业务服务器140发送该第一请求包；在此过程中，客户端110可以根据其对于第一请求包的发包操作生成打点信息，并将所生成的打点信息上传至故障检测服务器130。在实际应用中，该客户端110可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，本申请在此不对客户端110做任何限定。
其中，网关服务器120用于接收客户端110发送的第一请求包，对该第一请求包进行相应地处理后，将其发送给业务服务器140；在此过程中，网关服务器120可以根据其对于第一请求包的发包操作和/或收包操作生成打点信息，并将所生成的打点信息上传至故障检测服务器130。在实际应用中，网关服务器120可以是网关集群中任意一台网关服务器，即网关服务器120可以部署在包括有多台网关服务器120的网关集群中。
其中，业务服务器140用于接收网关服务器120转发的第一请求包，生成与该第一请求包对应的第二请求包，并通过网关服务器120向客户端110返回该第二请求包。
其中，网关服务器120还用于接收业务服务器140发送的第二请求包，对该第二请求包进行相应地处理后，将其发送给客户端110；在此过程中，网关服务器120可以根据其对于第二请求包的发包操作和收包操作生成的打点信息，并将所生成的打点信息上传至故障检测服务器130。
其中，客户端110还用于接收网关服务器120发送的第二请求包，并且根据其对于第二请求包的收包操作生成打点信息，将所生成的打点信息上传至故障检测服务器130。
需要说明的是，在本申请实施例提供的技术方案中，上述第一请求包和第二请求包均属于本申请实施例中的探测请求包。业务服务器140接收到客户端通过网关服务器120发送的第一请求包后，针对该第一请求包生成第二请求包，并通过网关服务器120向客户端反馈该第二请求包，在此过程中，上述第一请求包和第二请求包实质上属于同一探测请求包，即该第一请求包和第二请求包中包括相同的请求包标识，示例性的，所属于同一探测请求包的第一请求包和第二请求包中可以包括相同的由源IP地址、源端口、目的IP地址和目的端口组成的四元组标识。
其中，故障检测服务器130用于执行本申请实施例提供的故障检测方法，在故障检测周期内，接收探测请求包所经过的网络设备(包括客户端110、网关服务器120、业务服务器140中的至少一个)各自上报的打点信息，并将包含同一请求包标识的打点信息，作为该请求包标识所对应的探测请求包的打点信息；进而，根据所获取探测请求包的打点信息对网关集群中的网关服务器120进行故障检测，故障检测服务器130具体进行故障检测的过程将在下文的方法实施例中详细介绍。
其中，外网交换机150用于将来自外网的请求包(如客户端110发送的第一请求包)转发给网关服务器120，以及将来自网关服务器120的请求包转发给客户端110。内网交换机160用于将来自内网的请求包(如业务服务器140发送的第二请求包)转发给网关服务器120，以及将来自网关服务器120的请求包转发给业务服务器140。
如图1所示，在实际应用中，客户端110发送的第一请求包经过网络传输后先到达外网交换机150，该外网交换机150可以将该第一请求包发送给网关集群中的某台网关服务器120，网关服务器120接收到第一请求包后，按照一定的选择策略选择一台业务服务器140，并将经通用路由封装(Generic Routing Encapsulation，GRE)协议封装后得到的第一请求包发送至内网交换机160，通过该内网交换机160将该第一请求包发送给业务服务器140。
业务服务器140接收到第一请求包后，生成与该第一请求包对应的第二请求包，并将该第二请求包发送给内网交换机160，由该内网交换机160将该第二请求包发送给网关集群中的某台网关服务器120，网关服务器120收到第二请求包后拆解经GRE协议封装的GRE头，进而将该拆解后的第二请求包通过外网交换机150返回给客户端110。
在上述图1所示的请求包传输过程中，客户端110和网关服务器120可以针对探测请求包生成对应的打点信息。具体的，如图2所示，客户端110发出第一请求包后，可以记录探测请求包对应的第一条打点信息TP1，也可以理解为记录一条染色链路的第一个点；当网关服务器120接收到第一请求包后，可以记录探测请求包对应的第二条打点信息TP2，也可以理解为记录一条染色链路的第二个点；当网关服务器120完成对第一请求包的处理，将该第一请求包发送给业务服务器140后，可以记录探测请求包对应的第三条打点信息TP3，也可以理解为记录一条染色链路上的第三个点；当网关服务器120接收到业务服务器140针对该第一请求包返回的第二请求包后，可以记录探测请求包对应的第四条打点信息TP4，也可以理解为一条染色链路上的第四个点；当网关服务器120完成对第二请求包的处理，将该第二请求包发送给客户端110后，可以记录探测请求包对应的第五条打点信息TP5，也可以理解为一条染色链路上的第五个点；当客户端110接收到该第二请求包后，可以记录探测请求包对应的第六条打点信息TP6，也可以理解为一条染色链路上的第六个点。
客户端110和网关服务器120完成探测请求包对应的打点信息的记录后，需要将其记录的探测请求包对应的打点信息发送给故障检测服务器130，以便故障检测服务器130基于这些打点信息检测网关集群中的网关服务器120是否存在故障，并在检测到存在故障的情况下定位网关服务器120的故障原因。
应理解，通常情况下，为了准确检测网关服务器120是否存在故障，客户端110与业务服务器140需要在故障检测周期内交互大量不同的探测请求包，相应地，故障检测服务器130可以获取到客户端110和网关服务器120针对这些探测请求包记录的打点信息，并基于大量探测请求包各自对应的打点信息，进行对于网关服务器120的故障检测。
需要说明的是，在实际应用中，除了可以由客户端110和网关服务器120向故障检测服务器130上报探测请求包的打点信息外，也可以由网关服务器120独自向故障检测服务器130上报探测请求包的打点信息，还可以由客户端110、网关服务器120和业务服务器140协同向故障检测服务器130上报探测请求包的打点信息，本申请在此不对故障检测服务器130所接收的打点信息的来源做任何限定。
下面通过方法实施例对本申请提供的故障检测方法进行详细介绍。
参见图3，图3为本申请实施例提供的故障检测方法的流程示意图。下述实施例以执行主体为故障检测服务器为例进行介绍。如图3所示，该故障检测方法包括以下步骤：
步骤301：在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息；所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息；所述网络设备包括客户端、网关服务器和业务服务器中的至少一个。
步骤302：将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息。
由于步骤301和步骤302的关联性较强，故下文将步骤301和步骤302整合起来，对步骤301和步骤302的整体实现过程进行介绍。
在故障检测周期内，客户端可以通过网关服务器与业务服务器交互大量的探测请求包，在每个探测请求包传输的过程中，网关服务器可以根据自身对于该探测请求包的发包操作和/或收包操作生成该探测请求包对应的打点信息，进而将所生成的打点信息发送给故障检测服务器。
为了保证故障检测服务器能够获知更完整的探测请求包对应的传输链路路径，在实际应用中，用于发送探测请求包的客户端也可以根据自身对于探测请求包的发包操作和收包操作，生成探测请求包对应的打点信息，并将所生成的打点信息发送给故障检测服务器。
需要说明的是，打点信息中通常包含有请求包标识，该请求包标识与生成该打点信息时所依据的探测请求包相对应，即打点信息中包含的请求包标识，实际上即为探测请求包对应的请求包标识；对应于同一探测请求包的各条打点信息应当包含相同的请求包标识，而对应于不同探测请求包的各条打点信息硬蛋包含不同的请求包标识。如此，便于故障检测服务器根据打点信息中包含的请求包标识，来识别该打点信息具体对应的探测请求包，进而便于故障检测服务器确定出一个探测请求包对应的所有打点信息，并基于此确定该探测请求包的传输路径。
由于一个探测请求包对应的各个打点信息通常可以标识该探测请求包对应的传输链路路径，因此，故障检测服务器可以通过分析大量探测请求包各自对应的传输链路路径，来检测网关服务器是否存在故障，这种利用打点信息标识探测请求包对应的传输链路路径的方式，与医学上利用同位素或荧光剂染色定位病因的方式相类似，因此本申请中基于打点信息定位网关服务器故障的方式也可以被称为染色。
需要说明的是，上述对于探测请求包的发包操作具体包括：发送第一请求包的操作和发送第二请求包的操作；上述对于探测请求包的收包操作具体包括：接收第一请求包的操作和接收第二请求包的操作。其中，第一请求包是客户端通过网关服务器向业务服务器发送的请求包，第二请求包是业务服务器针对其接收的第一请求包生成的请求包，业务服务器需要通过网关服务器向客户端反馈该第二请求包，第二请求包与第一请求包之间具有对应关系，并且具有对应关系的第一请求包和第二请求包属于同一探测请求包，其中包含相同的请求包标识。
更具体的，对于网关服务器来说，其需要根据自身接收客户端发送的第一请求包的操作生成一条探测请求包对应的打点信息，根据自身向业务服务器发送第一请求包的操作生成一条探测请求包对应的打点信息，根据自身接收业务服务器发送的第二请求包的操作生成一条探测请求包对应的打点信息，根据自身向客户端发送第二请求包的操作生成一条探测请求包对应的打点信息。对于客户端来说，其需要根据自身发送第一请求包的操作生成一条探测请求包对应的打点信息，以及根据自身接收第二请求包的操作生成一条探测请求包对应的打点信息。
在网关服务器不存在故障的情况下，对于一个探测请求包，故障检测服务器至少应当接收到与该探测请求包对应的六条打点信息，这六条打点信息能够表示出探测请求包对应的完整的传输链路路径。反之，若对于一个探测请求包，故障检测服务器没有接收到六条打点信息，则说明该探测请求包在传输的过程中被丢包，进一步反映出网关服务器可能存在故障。
示例性的，如图2所示，本申请定义了6个记录并上传打点信息的节点：客户端已发包TP_CLIENT_SEND(简称为TP1)、网关服务器入方向已收包TP_LD_FRONT_RCV(简称为TP2)、网关服务器入方向已发包TP_LD_FRONT_SND(简称为TP3)、网关服务器出方向已收包TP_LD_BACK_RCV(简称为TP4)、网关服务器出方向已发包TP_LD_BACK_RCV(简称为TP5)、客户端已收包TP_CLIENT_RCV(简称为TP6)。上述入方向是指传输第一请求包的方向，上述出方向是指传输与第一请求包对应的第二请求包的方向。
具体的，客户端发出第一请求包后，可以记录探测请求包对应的第一条打点信息trace_point＝TP1，也可以理解为记录一条染色链路的第一个点；当网关服务器接收到第一请求包后，可以记录探测请求包对应的第二条打点信息trace_point＝TP2，也可以理解为记录一条染色链路的第二个点；当网关服务器完成对第一请求包的处理，将该第一请求包发送给业务服务器后，可以记录探测请求包对应的第三条打点信息trace_point＝TP3，也可以理解为记录一条染色链路上的第三个点；当网关服务器接收到业务服务器针对该第一请求包返回的第二请求包后，可以记录探测请求包对应的第四条打点信息trace_point＝TP4，也可以理解为一条染色链路上的第四个点；当网关服务器完成对第二请求包的处理，将该第二请求包发送给客户端后，可以记录探测请求包对应的第五条打点信息trace_point＝TP5，也可以理解为一条染色链路上的第五个点；当客户端接收到该第二请求包后，可以记录探测请求包对应的第六条打点信息trace_point＝TP6，也可以理解为一条染色链路上的第六个点。
应理解，在实际应用中，为了保证故障检测服务器能够获知更完整的探测请求包对应的传输链路路径，业务服务器也可以根据自身对于探测请求包进行的发包操作和/或收包操作生成打点信息，并将所生成的打点信息上报至故障检测服务器。具体的，业务服务器接收到网关服务器转发的来自客户端的第一请求包后，可以相应地生成一条打点信息上报至故障检测服务器，业务服务器针对第一请求包生成第二请求包，并将第二请求包发送给网关服务器(以通过该网关服务器将该第二请求包转发给客户端)后，可以相应地生成一条打点信息上报至故障检测服务器。在该种场景下，若网关服务器不存在故障，对于一个探测请求包(其中包括具有对应关系的第一请求包和第二请求包)，故障检测服务器应接收到与该探测请求包对应的八条打点信息，这八条打点信息能够表示出探测请求包对应的完整的传输链路路径。
可选的，为了使故障检测服务器能够更准确地基于探测请求包对应的传输链路路径分析网关服务器是否存在故障，通常需要保证在一个故障检测周期内客户端发出的多个探测请求包均不相同，从而避免故障检测服务器对其接收的打点信息产生混淆，不清楚其具体对应的探测请求包。
具体的，可以利用四元组标识唯一表征探测请求包，即采用四元组标识作为同一探测请求包对应的各条打点信息的请求包标识，四元组标识中包括源IP地址cip、源端口cport、目的IP地址vip和目的端口vport；相应地，在一个故障检测周期内，可以控制客户端和业务服务器交互所对应的四元组标识各不相同的探测请求包，由此故障检测服务器在故障检测周期内，将接收到多个分别包含不同的四元组标识的的打点信息。
即可以利用(cip，cport，vip，vport)四元组作为探测请求包的唯一标识，通过传输控制协议(Transmission Control Protocol，TCP)传递给网关服务器和业务服务器；在实际设计中，由于cport有60000+个可以使用，客户端可以对特定业务规则(vip，vport)每5s拨测一次，因此，使用上述四元组标识探测请求包通常需要几天才会重复交互同一个探测请求包(即对应相同标识四元组的探测请求包)，而一个故障检测周期通常是分钟级别的，由此可以保证故障检测服务器在一个故障检测周期内可以获取到对应于不同的四元组标识的探测请求包所对应的打点信息，如此达到染色的目的。
步骤302：根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。
故障检测服务器获取到探测请求包对应的打点信息后，可以基于所获取的打点信息，对网关服务器进行多个维度的故障检测，如检测网关服务器是否故障、网关服务器是否存在抖动性丢包故障、网关服务器是否存在异常的业务规则等等。
在一些实施例中，故障检测服务器可以根据打点信息检测网关集群中的网关服务器是否故障，即当网关集群的转发成功率出现下降告警时，故障检测服务器可以根据其获取到的打点信息，定位网关集群中出现故障的网关服务器。
具体的，可以将网关服务器根据其与探测请求包相关的收包操作生成的打点信息分为前端收包信息和后端收包信息，其中，前端收包信息是网关服务器对第一请求包完成收包操作时生成的记录信息，后端收包信息是网关服务器对第二请求包完成收包操作时生成的记录信息，其中，第一请求包是客户端通过网关服务器向业务服务器发送的请求包，该第二请求包是业务服务器接收到第一请求包后，通过网关服务器向客户端反馈的请求包，该第一请求包和第二请求包中包含相同的请求包标识。进而，故障检测服务器可以针对网关集群中每台网关服务器，根据该网关服务器上传的前端收包信息和后端收包信息，分别统计该网关服务器的前端收包数和后端收包数，并根据网关集群中各台网关服务器的前端收包数和后端收包数，确定网关集群中的故障网关服务器。
示例性的，在客户端和网关服务器需要向故障检测服务器上传打点信息包括TP1至TP6的情况下，TP2属于前端收包信息，TP4属于后端收包信息。针对网关集群中的每台网关服务器，故障检测服务器需要统计该网关服务器上传的TP2的数量(即前端收包数)，以及该网关服务器上传的TP4的数量(即后端收包数)；进而，根据网关集群中各台网关服务器上传的TP2的数量和TP4的数量，确定出网关集群中的故障网关服务器。
在一种可能的实现方式中，故障检测服务器可以根据网关服务器的前端收包数和/或后端收包数是否掉底，来确定故障网关服务器。即故障检测服务器可以针对网关集群中的每台网关服务器，判断该网关服务器的前端收包数和后端收包数是否掉底，若前端收包数和后端收包数中任一项或多项掉底，则可以确定该网关服务器为故障网关服务器。
具体的，故障检测服务器可以根据网关集群中各台网关服务器的前端收包数，绘制网关集群对应的前端收包数曲线图，进而，根据网关集群对应的前端收包数曲线，判断网关集群中是否存在前端收包数掉底的网关服务器，若存在，即可直接确定前端收包数掉底的网关服务器为故障网关服务器。相类似地，故障检测服务器可以根据网关集群中各台网关服务器的后端收包数，绘制网关集群对应的后端收包数曲线图，进而，根据网关集群对应的后端收包数曲线，判断网关集群中是否存在后端收包数掉底的网关服务器，若存在，即可直接确定后端收包数掉底的网关服务器为故障网关服务器。
在另一种可能的实现方式中，故障检测服务器可以通过判断网关服务器的前端收包数和/或后端收包数是否明显低于网关集群中其它网关服务器的前端收包数和/或后端收包数，来确定故障网关服务器。即故障检测服务器可以根据网关集群中各台网关服务器的前端收包数和后端收包数，分别确定前端收包平均阈值和后端收包平均阈值；进而，针对网关集群中每台网关服务器，确定前端收包平均阈值与该网关服务器的前端收包数之间的第一差值，并判断该第一差值是否超过预设前端差值阈值，若是，则确定该网关服务器为故障网关服务器；以及，针对网关集群中每台网关服务器，确定后端收包平均阈值与该网关服务器的后端收包数之间的第二差值，并判断该第二差值是否超过预设后端差值阈值，若是，则确定该网关服务器为故障网关服务器。
具体的，故障检测服务器可以根据网关集群中各台网关服务器的前端收包数，绘制网关集群对应的前端收包曲线图，该前端收包数曲线图能够反映网关集群的前端收包平均阈值；进而，故障检测服务器可以根据网关集群对应的前端收包数曲线图，判断是否存在前端收包数明显低于其它网关服务器的前端收包数的网关服务器，即判断是否存在前端收包数与前端收包平均阈值之间的差值超过预设前端差值阈值的网关服务器，若存在，则可以直接将该网关服务器确定为故障网关服务器。
相类似地，故障检测服务器可以根据网关集群中各台网关服务器的后端收包数，绘制网关集群对应的后端收包曲线图，该后端收包数曲线图能够反映网关集群的后端收包平均阈值；进而，故障检测服务器可以根据网关集群对应的后端收包数曲线图，判断是否存在后端收包数明显低于其它网关服务器的后端收包数的网关服务器，即判断是否存在后端收包数与后端收包平均阈值之间的差值超过预设后端差值阈值的网关服务器，若存在，则可以直接将该网关服务器确定为故障网关服务器。
如此，在检测到网关集群的转发成功率出现下降告警时，根据网关服务器上传的打点信息(即前端收包信息和后端收包信息)快速准确地定位网关集群中的故障网关服务器，即定位网关集群中转发性能存在故障的网关服务器。相比现有技术中由运维人员逐一检测各台网关服务器的流量情况，来定位故障网关服务器的实现方式，本申请实施例提供的方式更加快速高效。
在一些实施例中，故障检测服务器还可以检测网关服务器是否存在抖动性丢包故障。具体的，当一台网关服务器存在抖动性丢包故障时，网关集群中每台网关服务器的收包数实际上是没有很大区别的，因此单纯地通过上述方式无法检测出网关服务器是否存在抖动性丢包故障。为了检测网关服务器的抖动性丢包故障，本申请实施例还提供了一种抖动性丢包故障的检测方式。
下面先结合图4所示的网络架构进行分析，以客户端—>网关服务器—>业务服务器的方向为例，外网交换机和网关集群中的多台网关服务器之间通过OSPF(Open ShortestPath First)路由协议组成邻居网络，该邻居网络中每台设备都可以获得等价的路由。相类似地，在业务服务器—>网关服务器—>客户端的方向上，内网交换机和网关集群中的多台网关服务器之间也通过OSPF路由协议组成了邻居网络。
在客户端—>网关服务器—>业务服务器的方向上，当第一请求包到达外网交换机时，外网交换机会通过一定的哈希策略将第一请求包近似等概率的分发到各台网关服务器上，示例性的，所采用的哈希策略可以是二元组哈希，即根据第一请求包中的源IP和目的IP进行哈希。相类似地，在业务服务器—>网关服务器—>客户端的方向上，当第二请求包到达内网交换机时，内网交换机也会通过一定的哈希策略将第二请求包近似等概率的分发到各台网关服务器上。
基于上述原理可以确定，在大多数基于OSPF路由协议组成的邻居网络中，如果邻居关系稳定，那么包括相同的源IP地址和目的IP地址的请求包总会落到一台固定的网关服务器上。基于此，故障检测服务器可以在数据分析程序中维护每一个IP地址组合(其中包括源IP地址和目的IP地址)到前端网关服务器(即第一请求包经过的网关服务器)和后端网关服务器(即第二请求包经过的网关服务器)的映射关系。
即，故障检测服务器可以获取历史探测请求包对应的打点信息；根据历史探测请求包对应的打点信息，确定历史探测请求包经过的前端网关服务器和后端网关服务器，该历史探测请求包包括历史第一请求包和历史第二请求包，历史第一请求包是客户端通过前端网关服务器向业务服务器发送的请求包，历史第二请求包是业务服务器接收到历史第一请求包后，通过后端网关服务器向客户端反馈的请求包；进而，构建历史探测请求包中包括的IP地址组合与该前端网关服务器、后端网关服务器之间的映射关系，该IP地址组合包括源IP地址和目的IP地址。
换言之，故障检测服务器可以自动地根据客户端和网关服务器上传的探测请求包对应的打点信息，学习探测请求包中包括的IP地址组合(cip，vip)与该第一请求包经过的前端网关服务器之间的映射关系，以及该IP地址组合(cip，vip)与第二请求包(对应于该第一请求包)经过的后端网关服务器之间的映射关系。
此外，考虑到业务服务器向网关服务器发送第二请求包时，会为该第二请求包封装一层GRE头放在该第二请求包的网络层前(如图4所示)，因此导致内网交换机中包含内层哈希(对应于不包括GRE头的请求包)和外层哈希(对应于包括GRE头的请求包)两种，由此引入一个新的问题，即对于内层哈希，内网交换机可以直接通过请求包中包括的IP地址组合确定出特定的网关服务器，但是对于外层哈希，内网交换机需要利用封装在GRE头中的IP地址组合(rs_ip，tsv)进行哈希，这种情况下对于包括相同IP地址组合的请求包来说，其通过的后端网关服务器可能存在不同。
为了解决上述问题，可以控制将目标客户端发送的历史第一请求发送至目标业务服务器，该目标客户端和目标业务服务器之间具有对应关系。即，可以在网关集群中建立专门用于探测的规则，并将这些规则设置成会话保持，在网关服务器转发第一请求包时，控制将同一台客户端发送的第一请求包(包括相同的cip)始终转发到同一台业务服务器上，即控制将目标客户端发送的第一请求包始终转发到目标业务服务器上，目标客户端和目标业务服务器具有对应关系，由于vip与tsv是固定对应的，因此包括相同的(cip，vip)的请求还是可以落到同一台后端网关服务器上。
构建出IP地址组合(cip，vip)与前端网关服务器、后端网关服务器之间的映射关系后，故障检测服务器可以基于该映射关系，对网关集群中的网关服务器进行抖动性故障检测。即，当故障检测服务器根据探测请求对应的打点信息确定探测请求包对应的传输链路不完整时，可以根据该传输链路中缺失的打点信息、探测请求包中包括的IP地址组合和上述映射关系，确定该探测请求包对应的目的网关服务器，并相应地更新该目的网关服务器对应的丢包次数。当目的网关服务器对应的丢包次数达到预设丢包次数阈值时，确定该目的网关服务器存在抖动性丢包故障。
示例性的，仍以图2所示的传输链路为例，假设该探测请求包对应的打点信息中缺失trace_point＝TP4，则故障检测服务器可以确定该探测请求包对应的传输链路不完整，由于缺失的是网关服务器接收到第二请求包后应当上传的打点信息，因此，可以确定属于后端网关服务器丢包。在该种情况下，故障检测服务器可以先确定该探测请求包中包括的IP地址组合(cip，vip)，然后确定包括该IP地址组合的映射关系，将该映射关系中的后端网关服务器确定该探测请求包对应的目的网关服务器，即表示该第二请求包应当传输至该目的网关服务器，但是实际上该目的网关服务器并未接收到该第二请求包，发生了抖动丢包的情况。进而，故障检测服务器可以记录该目的网关服务器对应的丢包次数加1。若网关集群中存在某台网关服务器对应的丢包次数达到预设丢包次数阈值，则可以确定该网关服务器存在抖动性丢包故障。
需要说明的是，由于现网环境是实时变换的，如果网关集群中的某台网关服务器突然下线，或者网关集群中突然上线一台网关服务器，那么故障检测服务器此前学习到的IP地址组合与前端网关服务器、后端网关服务器之间的映射关系也会相应地发生改变，换言之，此前学习到的映射关系将不能继续应用在当前的网络环境中，如果继续应用该映射关系，将可能出现抖动性丢包误检测的情况。为此，本申请实施例还提供了一种检测映射关系是否有效的方案。
即，故障检测服务器根据其接收的探测请求包对应的打点信息，确定该探测请求包经过的前端网关服务器和后端网关服务器，该探测请求包包括第一请求包和第二请求包，该第一请求包是客户端通过前端网关服务器向业务服务器发送的请求包，该第二请求包是业务服务器接收到第一请求包后，通过后端网关服务器向客户端反馈的请求包。然后，根据该探测请求包中包括的目标IP地址组合，确定包括该目标IP地址组合的目标映射关系；进而，判断该探测请求包经过的前端网关服务器与该目标映射关系中的前端网关服务器是否一致，以及判断该探测请求包经过的后端网关服务器与目标映射关系中的后端网关服务器是否一致，若存在任一项或多项不一致，则可以确定目标映射关系失效，需要更新该目标映射关系。
具体的，故障检测服务器接收到探测请求包对应的打点信息后，可以确定该探测请求包中的第一请求包经过的前端网关服务器，以及与该探测请求包中的第二请求包经过的后端网关服务器；然后，根据该探测请求包中包括的目标IP地址组合(cip，vip)，确定包括该(cip，vip)的目标映射关系；进而，判断该目标映射关系中包括的前端网关服务器与该第一请求包实际经过的前端网关服务器是否一致，以及该目标映射关系中包括的后端网关服务器与该第二请求包实际经过的后端网关服务器是否一致，若存在任意一项不一致，则说明该目标映射关系已经不适用于现在的网络环境，相应地，故障检测服务器不再继续基于该目标映射关系进行抖动性丢包故障的检测，而是基于此后接收的探测请求包对应的打点信息重新学习映射关系，直至所学习的映射关系达到稳定，再基于新学习的映射关系进行抖动性丢包故障的检测。
应理解，在实际应用中，为了实现容错处理，故障检测服务器也可以针对映射关系确定失效阈值n(n为大于1的整数)，即在确定出n次映射关系中的前端网关服务器或者后端网关服务器，与第一请求包实际经过的前端网关服务器或者第二请求包实际经过的后端网关服务器不一致的情况下，再确定该映射关系失效。
在一些实施例中，故障检测服务器还可以检测网关服务器中是否存在异常的业务规则。具体的，网关服务器上报的打点信息可以包括：网关服务器根据对于探测请求包进行丢包操作时生成的丢包记录信息，该丢包记录信息中包括探测请求包的丢包原因；故障检测服务器获取到此类丢包记录信息后，可以根据这些丢包记录信息，分析网关服务器是否存在异常的业务规则。
下面先结合图5，对网关服务器中主转发程序umod的转发流程进行介绍。如图5所示，第一请求包到达网关服务器中的网卡后，会通过RSS(Receive Side Scaling)均匀地分发到网卡的多个RX队列中，各个RX队列分别对应umod程序中的一个RX线程，RX线程接收到第一请求包后，根据该第一请求包中包括的(cip，vip)，将该第一请求包哈希到负责业务处理的TX线程，TX线程对该第一请求包进行合法性检查、转发规则匹配、过载限速安全组检查、封包等处理，然后将处理后的第一请求包发送到与该TX线程绑定的TX队列上，进而，通过该TX队列将第一请求包发送给业务服务器，如此完成对于第一请求包的转发。应理解，网关服务器对于第二请求包的处理方式实际上与上述对于第一请求包的处理方式类似，只存在传输方向不同的区别而已。
基于本申请实施例提供的方法，网关服务器可以对探测请求包(包括第一请求包和第二请求包)的处理操作进行记录，类似于医学上利用同位素和荧光染色来定位病原，基于请求包对应的清晰的传输链路信息，清楚直接地定位故障位置。
具体的，在本申请实施例提供的方法中，可以改造网关服务器中的umod程序，使其对于请求包的各个处理环节进行打点记录，如果一个探测请求包被丢掉，则通过drop_point记录丢包记录信息，并启动数据收集线程，将所记录的丢包记录信息传输至故障检测服务器。进而，故障检测服务器可以定期对其收集的丢包记录信息进行分析，以实现对于异常业务规则的全方位跟踪定位。
示例性的，可以在网关服务器的转发逻辑中定义如下丢包记录信息：
//RX
DP_PORT_RX_MBUF_EMPTY＝100,//RXmbuf为空
DP_PORT_RX_ENQUEUE_FAIL＝105,//RX出队列失败
//TXbeforesched
DP_VIP_NOT_EXIST＝200,//VIP不存在
DP_RULE_NOT_EXIST＝205,//规则不存在
DP_INVALID_VLANID＝210,//VLANID非法
DP_MARTIAN_SOURCE＝215,//非法报文
DP_NOT_SYN_SCHED＝220,//TPC，无连接表，收到非syn报文
DP_INVALID_RS_TYPE＝225,//RS类型错误
DP_DEST_UNAVAILABLE＝230,//RS不可用
DP_DEST_OFFLINE＝235,//RS不在线
DP_SESSION_CREATE_FAIL＝240,//创建session失败
//TXlimitandflowcontrol
DP_FLOW_OVERLOAD＝300,//流量过载
DP_CONN_OVERLOAD＝305,//连接数超限
DP_CONN_CREATE_FAIL＝310,//新建连接失败
DP_IN_BLACKLIST＝315,//请求在黑名单中
DP_NOT_IN_WHITHLIST＝320,//请求不在白名单中
DP_FLOW_LIMIT＝325,//流量限速
DP_CTRL_DROP＝330,//辅助进程丢包，废弃，后续版本会删除
DP_CTRL_FREE_CONN＝335,//辅助进程丢弃连接，废弃，后续版本会删除
//TXpacketencap封包相关
DP_MANGLE_INNER_FAIL＝400，//修改报文失败
DP_TUNNEL_ENCAP_FAIL＝405,//封装隧道头失败
DP_ROUTE_LOOKUP_FAIL＝410,//路由查找失败
//TXxmit发包相关
DP_XMIT_FAIL＝500,//发包失败
应理解，在实际应用中，除了可以定义上述丢包记录信息外，还可以根据实际需求定义其它丢包记录信息，本申请在此不对所定义的丢包记录信息做任何限定。
相比相关技术中通过在网关服务器上部署抓包程序，根据网关服务器的抓包结果定位异常的业务规则的实现方式，本申请实施例提供的定位异常业务规则的方式，能够根据网关服务器上传的丢包打点信息全方位地跟踪业务规则，有效地提高异常业务规则的定位效率和定位准确性，
可选的，考虑到客户端和业务服务器通常基于TCP协议进行通信，客户端和业务服务器经过三次握手后，业务服务器会感知到通信的建立，并为客户端相应地分配处理资源，而实际上在对网关服务器进行故障检测的过程中，业务服务器为客户端分配的处理资源并不会被客户端真正的利用，因此，为了避免业务服务器为客户端分配无用的处理资源，对业务服务器的处理资源造成不必要的浪费，本申请实施例还提供了一种在对网关服务器进行故障检测的过程中使得业务服务器无感知的方法。
即控制防火墙拦截客户端向业务服务器发送的第三次握手反馈信息，并控制内核向业务服务器发送响应失败消息。
具体的，如图6所示，客户端可以从应用层程序发起scoket连接请求，利用Linux内核协议栈TCP三次握手的过程进行探测，当与业务服务器完成前两次握手后，利用防火墙将第三次握手ack拦截掉，从而阻止TCP建联成功，由此业务服务器将不会感知到此次探测请求包，也不会为客户端分配处理资源。最后，为了防止上述半连接状态占用服务器资源，客户端可以在此次探测结束后通知内核向业务服务器发送rst，以结束整个流程。如此，整个探测过程中和网关服务器只进行了一次完整的数据交互，并且做到了业务服务器无感知，十分轻量。
上述本申请实施例提供的故障检测方法，借鉴医学上利用同位素或荧光剂染色定位病因的方式，对互联网中经过网关服务器的探测请求包进行全链路染色打点，即利用客户端和/或网关服务器根据与探测请求包相关的发包操作和收包操作生成打点信息，得到探测请求包对应的打点信息，进而，基于在故障检测周期内获取到的多个探测请求包各自对应的打点信息，对网关服务器进行故障检测，以准确检测网关服务器是否存在故障，并在检测到存在故障的情况下定位故障位置和故障原因。如此，基于探测请求包的传输链路路径，实现复杂网络环境中网关服务器的故障检测及定位。
下面介绍一种示例性的上述故障检测方法所应用的故障检测系统，该故障检测系统也可以被称为染色系统。如图7所示，该染色系统包括探测客户端(可以由服务器作为探测客户端)、日志收集存储系统、日志转发服务器(gw_probe_proxy)、日志分析服务器(gw_probe_brain)和运营系统。其中，日志收集存储系统用于收集存储网关服务器记录的打点信息；日志转发服务器(gw_probe_proxy)用于将探测客户端记录的打点信息以及日志收集存储系统存储的打点信息，转发给日志分析服务器(gw_probe_brain)，该日志分析服务器(gw_probe_brain)实质上即为上文中的故障检测服务器，用于执行上述故障检测方法；运营系统面向运维工作人员。该染色系统可以提供实时监控网关服务器、追溯网关服务器故障等功能，服务于网关系统的现网环境。
对于探测客户端和探测点的选择，由于外网交换机和内网交换机与网关集群中的多台网关服务器均是负载均衡的关系，因此，无论是入包方向还是回包方向，均要保证对于网关集群的拨测能够覆盖该网关集群的所有网关服务器，通常情况下，网关集群中可以包括4到8台网关服务器。
基于此，对于入包方向，可以采用30台探测服务器分3地部署的方式，在每个地区各部署10台探测服务器作为一组，全部采用cap(Consistency，Availability，Partitiontolerance)网络，以排除运营商网络质量、单点拨测机故障对拨测结果产生影响。对于回包方向，每个网关集群均设置专门用于拨测的规则，并在这些规则后面挂接20到30台业务服务器，分布于多地机房，以保证业务服务器的回包可以覆盖到网关集群中的所有网关服务器。
对于数据汇总分析，染色系统的一个主要功能是进行线上网关集群的健康性监控，因此对数据的实时性、准确性要求较高。染色打点记录首先都是通过日志的形式记录在本地的，然后利用云架构平台的日志采集功能将日志汇总到kafla缓存，由于数据源有两份(分别是客户端的数据源和网关服务器的数据源)，因此，进行分析时需要将两份数据源汇聚在一次，即需要在一台机器的内存空间中完成汇聚，考虑到数据量巨大，单台机器可能无法处理过来，因此需要采用分布式的方式。具体设计以下两种方案可供选择：
方案一：利用Spark进行实时分析。但是这种方式存在以下问题：客户端和网关服务器记录的打点信息分属于多个kafla源，将同一拨测的所有打点信息都转发到Spark集群的同一台机器上，实现较为复杂，并且Spark作为一个庞大的数据分析系统需要巨大的维护成本和专门的人力支持，一旦出现问题，对于问题的定位极为困难。
方案二：开发日志转发gw_probe_proxy和日志分析gw_probe_brain两个程序。如图8所示，日志转发程序gw_probe_proxy仅进行哈希转发，保证基于标识四元组将同一拨测整体链路的打点信息转发到同一日志分析程序gw_probe_brain，这样多个日志分析程序gw_probe_brain之间完全没有联系，可以实现平行扩展。日志分析程序gw_probe_brain中的插件1可以基于打点信息进行数据分析，并将数据分析结果提供给健康中心决策程序，由此在秒级内完成数据处理，保证线上监控的实时性、可用性。
此外，日志分析程序gw_probe_brain中的插件2可以在接收打点失败时，通知日志转发程序gw_probe_proxy中的反馈/重传模块，使其重新发送没有被成功接收的打点信息。日志分析程序gw_probe_brain中的插件2还可以把汇聚后完整的链路数据发给负责离线处理的鹊方平台。
染色系统除了可以进行线上监控外，还可以作为网络问题分析工具使用，运维工作人员在定位问题时可能需要查看历史的打点信息，由于历史数据量巨大(每天可达10T+)且维度很多，利用传统查数据库建立索引的方式很难满足时间需求。为了解决该问题，本申请接入鹊方平台，如图7和图8所示，利用ES(Elastic Search)的倒排索引实现数据快速离线查询，TB级别的数据可以在1s内查出结果。
在实际应用中，上述图7所示的染色系统可以达到以下效果：
1、自动容错—秒级监控集群问题
探测请求包对应的打点信息每20s统计上报一次，故障检测服务器可以在1分钟内作出决策，在现网自动容错中起到了至关重要的作用，极大地减少了网关现网问题单数。以一个网关集群包括两台网关服务器(x.x.x.101和x.x.x.102)为例，在两种不同的情况下，故障检测效果分别如下：
当一台网关服务器完成不能转发时，如图9所示，网关集群整体转发成功率下降，基于该网关服务器上传的前端收包信息统计出的前端收包数、以及基于该网关服务器上传的后端收包信息统计出的后端收包数出现明显下降，如此可以判断该网关服务器出现故障。
当一台网关服务器出现抖动性丢包故障时，如图10所示，网关集群整体转发成功率下降，但是从网关服务器的收包数量上来看两台网关服务器并无并行差异，但是故障检测服务器可以通过IP路由学习，成功统计出丢掉的包全部属于x.x.x.101这台服务器，因此可以锁定该台服务器存在抖动性丢包故障。
2、运营工具—离线统计辅助日常问题定位
除了可以基于探测请求包对应的打点信息进行网关服务器的实时监控外，还可以提供日志问题的定位，例如，运维人员可以基于染色系统提供的离线数据分析界面分析指定的探测请求包的全链路信息，从而进行业务反馈的异常问题定位。
针对上文描述的故障检测方法，本申请还提供了对应的故障检测装置，以使上述故障检测方法在实际中的应用以及实现。
参见图11，图11为上文图3所示的故障检测方法对应的一种故障检测装置1100的结构示意图，该故障检测装置1100包括：
信息获取模块1101，用于在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息；所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息；所述网络设备包括客户端、网关服务器和业务服务器中的至少一个；
所述信息获取模块1101，还用于将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息；
故障检测模块1102，用于根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。
可选的，在图11所示的故障检测装置的基础上，所述网络设备包括所述网关服务器，所述网关服务器部署在网关集群中，所述网关集群包括多台所述网关服务器；所述网关服务器上报的打点信息包括：前端收包信息和后端收包信息，所述前端收包信息是所述网关服务器对第一请求包完成收包操作时生成的记录信息，所述后端收包信息是所述网关服务器对第二请求包完成收包操作时生成的记录信息，所述第一请求包是所述客户端通过所述网关服务器向所述业务服务器发送的请求包，所述第二请求包是所述业务服务器接收到所述第一请求包后，通过所述网关服务器向所述客户端反馈的请求包，所述第二请求包与所述第一请求包中包含相同的请求包标识。参见图12，图12为本申请实施例提供的另一种故障检测装置1200的结构示意图。如图12所示，所述故障检测模块1102包括：
收包数统计单元1201，用于针对所述网关集群中每台所述网关服务器，根据所述网关服务器上传的所述前端收包信息和所述后端收包信息，分别统计所述网关服务器的前端收包数和后端收包数；
故障确定单元1202，用于根据所述网关集群中各台所述网关服务器的前端收包数和后端收包数，确定所述网关集群中的故障网关服务器。
可选的，在图12所示的故障检测装置的基础上，所述故障确定单元1202具体用于：
针对所述网关集群中每台所述网关服务器，判断所述网关服务器的前端收包数和后端收包数是否掉底，若所述前端收包数和所述后端收包数中任一项或多项掉底，则确定所述网关服务器为所述故障网关服务器。
可选的，在图12所示的故障检测装置的基础上，所述故障确定单元1202具体用于：
根据所述网关集群中各台所述网关服务器的前端收包数和后端收包数，分别确定前端收包平均阈值和后端收包平均阈值；
针对所述网关集群中每台所述网关服务器，确定所述前端收包平均阈值与所述网关服务器的前端收包数之间的第一差值，判断所述第一差值是否超过预设前端差值阈值，若是，则确定所述网关服务器为所述故障网关服务器；
针对所述网关集群中每台所述网关服务器，确定所述后端收包平均阈值与所述网关服务器的后端收包数之间的第二差值，判断所述第二差值是否超过预设后端差值阈值，若是，则确定所述网关服务器为所述故障网关服务器。
可选的，在图11所示的故障检测装置的基础上，所述网络设备至少包括所述客户端和所述网关服务器；所述网关服务器部署在网关集群中，所述网关集群包括多台所述网关服务器。参见图13，图13为本申请实施例提供的另一种故障检测装置1300的结构示意图。如图13所示，所述装置还包括：
映射关系构建模块1301，用于获取历史探测请求包的打点信息；根据所述历史探测请求包的打点信息，确定所述历史探测请求包经过的前端网关服务器和后端网关服务器；所述历史探测请求包包括历史第一请求包和历史第二请求包，所述历史第一请求包是所述客户端通过所述前端网关服务器向所述业务服务器发送的请求包，所述历史第二请求包是所述业务服务器接收到所述历史第一请求包后，通过所述后端网关服务器向所述客户端反馈的请求包；构建所述历史探测请求包中包括的IP地址组合与所述前端网关服务器、所述后端网关服务器之间的映射关系；所述PI地址组合包括源IP地址和目的IP地址。
可选的，在图13所示的故障检测装置的基础上，所述映射关系构建模块1301还用于：
控制目标客户端发送所述历史第一请求包至目标业务服务器；所述目标客户端与所述目标业务服务器之间具有对应关系。
可选的，在图13所示的故障检测装置的基础上，所述故障检测模块1102具体用于：
当根据所述探测请求包的打点信息确定所述探测请求包对应的传输链路不完整时，根据所述传输链路中缺失的打点信息、所述探测请求包中包括的IP地址组合和所述映射关系，确定所述探测请求包对应的目的网关服务器，并更新所述目的网关服务器对应的丢包次数；
当所述目的网关服务器对应的丢包次数达到预设丢包次数阈值时，确定所述目的网关服务器存在抖动性丢包故障。
可选的，在图13所示的故障检测装置的基础上，所述映射关系构建模块1301还用于：
根据所述探测请求包的打点信息，确定所述探测请求包经过的前端网关服务器和后端网关服务器；所述探测请求包包括第一请求包和第二请求包，所述第一请求包是所述客户端通过所述前端网关服务器向所述业务服务器发送的请求包，所述第二请求包是所述业务服务器接收到所述第一请求包后，通过所述后端网关服务器向所述客户端反馈的请求包；
根据所述探测请求包中包括的目标IP地址组合，确定包括所述目标IP地址组合的目标映射关系；
判断所述探测请求包经过的前端网关服务器与所述目标映射关系中的前端服务器是否一致，以及所述探测请求包经过的后端网关服务器与所述目标映射关系中的后端服务器是否一致，若存在任一项或多项不一致，则确定所述目标映射关系失效，需要更新所述目标映射关系。
可选的，在图11所示的故障检测装置的基础上，所述网络设备包括所述网关服务器，所述网关服务器上报的打点信息包括：所述网关服务器对所述探测请求包进行丢包操作时生成的丢包记录信息，所述丢包记录信息包括所述探测请求包的丢包原因；则所述故障检测模块1102具体用于：
根据所述网关服务器上报的所述丢包记录信息，分析所述网关服务器是否存在异常的业务规则。
可选的，在图11所示的故障检测装置的基础上，所述请求包标识为四元组标识，所述四元组标识包括源IP地址、源端口、目的IP地址和目的端口；则所述信息获取模块1101具体用于：
在所述故障检测周期内，接收多个分别包含不同的四元组标识的打点信息。
可选的，在图11所示的故障检测装置的基础上，当所述客户端与所述业务服务器基于传输控制协议TCP通信时。参见图14，图14为本申请实施例提供的另一种故障检测装置1400的结构示意图。如图14所示，所述装置还包括：
通信控制模块1401，用于控制防火墙拦截所述客户端向所述业务服务器发送的第三次握手反馈信息；控制内核向所述业务服务器发送响应失败消息。
上述本申请实施例提供的故障检测装置，借鉴医学上利用同位素或荧光剂染色定位病因的方式，对互联网中经过网关服务器的探测请求包进行全链路染色打点，即利用网关服务器和/或客户端根据与探测请求包相关的发包操作和收包操作生成打点信息，得到探测请求包对应的打点信息，进而，基于在故障检测周期内获取到的多个探测请求包各自对应的打点信息，对网关服务器进行故障检测，以准确检测网关服务器是否存在故障，并在检测到存在故障的情况下定位故障位置和故障原因。如此，基于探测请求包的传输链路路径，实现复杂网络环境中网关服务器的故障检测及定位
本申请实施例还提供了一种用于检测网关服务器故障的设备，该设备具体可以为服务器，下面将从硬件实体化的角度对本申请实施例提供的服务器进行介绍。
参见图15，图15为本申请实施例提供的一种服务器1500的结构示意图。该服务器1500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)1522(例如，一个或一个以上处理器)和存储器1532，一个或一个以上存储应用程序1542或数据1544的存储介质1530(例如一个或一个以上海量存储设备)。其中，存储器1532和存储介质1530可以是短暂存储或持久存储。存储在存储介质1530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1522可以设置为与存储介质1530通信，在服务器1500上执行存储介质1530中的一系列指令操作。
服务器1500还可以包括一个或一个以上电源1526，一个或一个以上有线或无线网络接口1550，一个或一个以上输入输出接口1558，和/或，一个或一个以上操作系统1541，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。
上述实施例中由服务器所执行的步骤可以基于该图15所示的服务器结构。
其中，CPU 1522用于执行如下步骤：
在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息；所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息；所述网络设备包括客户端、网关服务器和业务服务器中的至少一个；
将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息；
根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。
可选的，CPU 1522还可以用于执行本申请实施例提供的故障检测方法的任意一种实现方式的步骤。
本申请实施例还提供一种计算机可读存储介质，用于存储计算机程序，该计算机程序用于执行前述各个实施例所述的一种故障检测方法中的任意一种实施方式。
本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行前述各个实施例所述的一种基于故障检测方法中的任意一种实施方式。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文全称：Read-OnlyMemory，英文缩写：ROM)、随机存取存储器(英文全称：Random Access Memory，英文缩写：RAM)、磁碟或者光盘等各种可以存储计算机程序的介质。
应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
Claims (15)
1.一种故障检测方法，其特征在于，所述方法包括：
在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息；所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息；所述网络设备包括客户端、网关服务器和业务服务器中的至少一个；
将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息；
根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。
2.根据权利要求1所述的方法，其特征在于，所述网络设备包括所述网关服务器，所述网关服务器部署在网关集群中，所述网关集群包括多台所述网关服务器；所述网关服务器上报的打点信息包括：前端收包信息和后端收包信息，所述前端收包信息是所述网关服务器对第一请求包完成收包操作时生成的记录信息，所述后端收包信息是所述网关服务器对第二请求包完成收包操作时生成的记录信息，所述第一请求包是所述客户端通过所述网关服务器向所述业务服务器发送的请求包，所述第二请求包是所述业务服务器接收到所述第一请求包后，通过所述网关服务器向所述客户端反馈的请求包，所述第二请求包与所述第一请求包中包含相同的请求包标识；
所述根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测，包括：
针对所述网关集群中每台所述网关服务器，根据所述网关服务器上传的所述前端收包信息和所述后端收包信息，分别统计所述网关服务器的前端收包数和后端收包数；
根据所述网关集群中各台所述网关服务器的前端收包数和后端收包数，确定所述网关集群中的故障网关服务器。
3.根据权利要求2所述的方法，其特征在于，所述根据所述网关集群中各台所述网关服务器的前端收包数和后端收包数，确定所述网关集群中的故障网关服务器，包括：
针对所述网关集群中每台所述网关服务器，判断所述网关服务器的前端收包数和后端收包数是否掉底，若所述前端收包数和所述后端收包数中任一项或多项掉底，则确定所述网关服务器为所述故障网关服务器。
4.根据权利要求2所述的方法，其特征在于，所述根据所述网关集群中各台所述网关服务器的前端收包数和后端收包数，确定所述网关集群中是否存在故障网关服务器，包括：
根据所述网关集群中各台所述网关服务器的前端收包数和后端收包数，分别确定前端收包平均阈值和后端收包平均阈值；
针对所述网关集群中每台所述网关服务器，确定所述前端收包平均阈值与所述网关服务器的前端收包数之间的第一差值，判断所述第一差值是否超过预设前端差值阈值，若是，则确定所述网关服务器为所述故障网关服务器；
针对所述网关集群中每台所述网关服务器，确定所述后端收包平均阈值与所述网关服务器的后端收包数之间的第二差值，判断所述第二差值是否超过预设后端差值阈值，若是，则确定所述网关服务器为所述故障网关服务器。
5.根据权利要求1所述的方法，其特征在于，所述网络设备至少包括所述客户端和所述网关服务器；所述网关服务器部署在网关集群中，所述网关集群包括多台所述网关服务器；所述方法还包括：
获取历史探测请求包的打点信息；
根据所述历史探测请求包的打点信息，确定所述历史探测请求包经过的前端网关服务器和后端网关服务器；所述历史探测请求包包括历史第一请求包和历史第二请求包，所述历史第一请求包是所述客户端通过所述前端网关服务器向所述业务服务器发送的请求包，所述历史第二请求包是所述业务服务器接收到所述历史第一请求包后，通过所述后端网关服务器向所述客户端反馈的请求包；
构建所述历史探测请求包中包括的IP地址组合与所述前端网关服务器、所述后端网关服务器之间的映射关系；所述PI地址组合包括源IP地址和目的IP地址。
6.根据权利要求5所述的方法，其特征在于，所述方法还包括：
控制目标客户端发送所述历史第一请求包至目标业务服务器；所述目标客户端与所述目标业务服务器之间具有对应关系。
7.根据权利要求5所述的方法，其特征在于，所述根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测，包括：
当根据所述探测请求包的打点信息确定所述探测请求包对应的传输链路不完整时，根据所述传输链路中缺失的打点信息、所述探测请求包中包括的IP地址组合和所述映射关系，确定所述探测请求包对应的目的网关服务器，并更新所述目的网关服务器对应的丢包次数；
当所述目的网关服务器对应的丢包次数达到预设丢包次数阈值时，确定所述目的网关服务器存在抖动性丢包故障。
8.根据权利要求5所述的方法，其特征在于，所述方法还包括：
根据所述探测请求包的打点信息，确定所述探测请求包经过的前端网关服务器和后端网关服务器；所述探测请求包包括第一请求包和第二请求包，所述第一请求包是所述客户端通过所述前端网关服务器向所述业务服务器发送的请求包，所述第二请求包是所述业务服务器接收到所述第一请求包后，通过所述后端网关服务器向所述客户端反馈的请求包；
根据所述探测请求包中包括的目标IP地址组合，确定包括所述目标IP地址组合的目标映射关系；
判断所述探测请求包经过的前端网关服务器与所述目标映射关系中的前端服务器是否一致，以及所述探测请求包经过的后端网关服务器与所述目标映射关系中的后端服务器是否一致，若存在任一项或多项不一致，则确定所述目标映射关系失效，需要更新所述目标映射关系。
9.根据权利要求1所述的方法，其特征在于，所述网络设备包括所述网关服务器，所述网关服务器上报的打点信息包括：所述网关服务器对所述探测请求包进行丢包操作时生成的丢包记录信息，所述丢包记录信息包括所述探测请求包的丢包原因；
所述根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测，包括：
根据所述网关服务器上报的所述丢包记录信息，分析所述网关服务器是否存在异常的业务规则。
10.根据权利要求1所述的方法，其特征在于，所述请求包标识为四元组标识，所述四元组标识包括源IP地址、源端口、目的IP地址和目的端口；所述在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息，包括：
在所述故障检测周期内，接收多个分别包含不同的四元组标识的打点信息。
11.根据权利要求1所述的方法，其特征在于，当所述客户端与所述业务服务器基于传输控制协议TCP通信时，所述方法还包括：
控制防火墙拦截所述客户端向所述业务服务器发送的第三次握手反馈信息；控制内核向所述业务服务器发送响应失败消息。
12.一种故障检测装置，其特征在于，所述装置包括：
信息获取模块，用于在故障检测周期内，接收探测请求包所经过的网络设备各自上报的打点信息；所述打点信息是所述网络设备对所述探测请求包进行操作时生成的记录信息；所述网络设备包括客户端、网关服务器和业务服务器中的至少一个；
所述信息获取模块，还用于将包含同一请求包标识的打点信息，作为所述请求包标识所对应的探测请求包的打点信息；
故障检测模块，用于根据所述探测请求包的打点信息，对所述网络设备进行网关故障检测。
13.一种故障检测系统，其特征在于，所述系统包括：客户端、网关服务器和故障检测服务器；
所述客户端，用于根据其对于探测请求包的发包操作和收包操作生成打点信息，并将所述打点信息上报至所述故障检测服务器；
所述网关服务器，用于根据其对于所述探测请求包的发包操作和收包操作生成打点信息，并将所述打点信息上报至所述故障检测服务器；
所述故障检测服务器，用于执行权利要求1至11任一项所述的故障检测方法。
14.一种设备，其特征在于，所述设备包括处理器及存储器；
所述存储器用于存储计算机程序；
所述处理器用于根据所述计算机程序执行权利要求1至11中任一项所述的故障检测方法。
15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行权利要求1至11中任一项所述的故障检测方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010909180.0A CN112073234B (zh) | 2020-09-02 | 一种故障检测方法、装置、系统、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010909180.0A CN112073234B (zh) | 2020-09-02 | 一种故障检测方法、装置、系统、设备及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112073234A true CN112073234A (zh) | 2020-12-11 |
| CN112073234B CN112073234B (zh) | 2024-06-28 |
Family
ID=
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113190278A (zh) * | 2021-03-18 | 2021-07-30 | 山东英信计算机技术有限公司 | 一种多场景故障处理方法、系统及介质 |
| CN113595783A (zh) * | 2021-07-27 | 2021-11-02 | 中国建设银行股份有限公司 | 故障的定位方法、装置、服务器及计算机存储介质 |
| CN113676369A (zh) * | 2021-07-15 | 2021-11-19 | 深圳赋乐科技有限公司 | 一种网络质量分析方法、数据接收服务器及存储介质 |
| CN114189426A (zh) * | 2021-10-29 | 2022-03-15 | 苏州浪潮智能科技有限公司 | 代理服务自适应带配置回复方法、系统、装置及存储介质 |
| CN114553678A (zh) * | 2022-02-09 | 2022-05-27 | 紫光云(南京)数字技术有限公司 | 一种云网络软slb流量问题的诊断方法 |
| CN115865734A (zh) * | 2022-12-02 | 2023-03-28 | 上海浦东发展银行股份有限公司 | 一种故障检测方法、数据生成方法、装置、设备及介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105743711A (zh) * | 2016-04-13 | 2016-07-06 | 华为技术有限公司 | 一种网络路径的故障检测方法、装置及网络设备 |
| CN107040816A (zh) * | 2017-03-17 | 2017-08-11 | 北京潘达互娱科技有限公司 | 一种客户端应用运行异常分析方法与装置 |
| CN109150650A (zh) * | 2017-06-28 | 2019-01-04 | 汤姆逊许可公司 | 通信故障报告的方法和对应的设备 |
| CN111030873A (zh) * | 2019-12-24 | 2020-04-17 | 迈普通信技术股份有限公司 | 一种故障诊断方法及装置 |
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105743711A (zh) * | 2016-04-13 | 2016-07-06 | 华为技术有限公司 | 一种网络路径的故障检测方法、装置及网络设备 |
| CN107040816A (zh) * | 2017-03-17 | 2017-08-11 | 北京潘达互娱科技有限公司 | 一种客户端应用运行异常分析方法与装置 |
| CN109150650A (zh) * | 2017-06-28 | 2019-01-04 | 汤姆逊许可公司 | 通信故障报告的方法和对应的设备 |
| CN111030873A (zh) * | 2019-12-24 | 2020-04-17 | 迈普通信技术股份有限公司 | 一种故障诊断方法及装置 |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113190278A (zh) * | 2021-03-18 | 2021-07-30 | 山东英信计算机技术有限公司 | 一种多场景故障处理方法、系统及介质 |
| CN113676369A (zh) * | 2021-07-15 | 2021-11-19 | 深圳赋乐科技有限公司 | 一种网络质量分析方法、数据接收服务器及存储介质 |
| CN113676369B (zh) * | 2021-07-15 | 2022-07-19 | 深圳赋乐科技有限公司 | 一种网络质量分析方法、数据接收服务器及存储介质 |
| CN113595783A (zh) * | 2021-07-27 | 2021-11-02 | 中国建设银行股份有限公司 | 故障的定位方法、装置、服务器及计算机存储介质 |
| CN113595783B (zh) * | 2021-07-27 | 2022-12-13 | 中国建设银行股份有限公司 | 故障的定位方法、装置、服务器及计算机存储介质 |
| CN114189426A (zh) * | 2021-10-29 | 2022-03-15 | 苏州浪潮智能科技有限公司 | 代理服务自适应带配置回复方法、系统、装置及存储介质 |
| CN114189426B (zh) * | 2021-10-29 | 2023-08-11 | 苏州浪潮智能科技有限公司 | 代理服务自适应带配置回复方法、系统、装置及存储介质 |
| CN114553678A (zh) * | 2022-02-09 | 2022-05-27 | 紫光云(南京)数字技术有限公司 | 一种云网络软slb流量问题的诊断方法 |
| CN114553678B (zh) * | 2022-02-09 | 2024-02-13 | 紫光云(南京)数字技术有限公司 | 一种云网络软slb流量问题的诊断方法 |
| CN115865734A (zh) * | 2022-12-02 | 2023-03-28 | 上海浦东发展银行股份有限公司 | 一种故障检测方法、数据生成方法、装置、设备及介质 |
| CN115865734B (zh) * | 2022-12-02 | 2024-06-07 | 上海浦东发展银行股份有限公司 | 一种故障检测方法、数据生成方法、装置、设备及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20180375748A1 (en) | Network traffic tracking using encapsulation protocol | |
| US11671342B2 (en) | Link fault isolation using latencies | |
| CN108028778B (zh) | 生成信息传输性能警告的方法、系统和装置 | |
| US10764148B2 (en) | Methods, systems, and computer readable media for network traffic statistics collection | |
| US9998955B1 (en) | Multi-tier stateful network flow management architecture | |
| US8005012B1 (en) | Traffic analysis of data flows | |
| Moradi et al. | Conmon: An automated container based network performance monitoring system | |
| US20110093579A1 (en) | Apparatus and system for estimating network configuration | |
| US10033602B1 (en) | Network health management using metrics from encapsulation protocol endpoints | |
| US10771363B2 (en) | Devices for analyzing and mitigating dropped packets | |
| CN113259143B (zh) | 信息处理方法、设备、系统及存储介质 | |
| CN114143203A (zh) | 一种基于动态服务拓扑映射的Kubernetes容器网络数据包指标采集的方法及系统 | |
| CN108462598A (zh) | 一种日志生成方法、日志分析方法及装置 | |
| CN107294743B (zh) | 一种网络路径探测方法、控制器及网络设备 | |
| CN115499230A (zh) | 网络攻击检测方法和装置、设备及存储介质 | |
| US10547560B1 (en) | Monitoring network communications queues | |
| Song et al. | HCMonitor: An accurate measurement system for high concurrent network services | |
| US11876838B2 (en) | Lawful interception chain in service providing networks | |
| CN112073234B (zh) | 一种故障检测方法、装置、系统、设备及存储介质 | |
| CN116723154A (zh) | 一种基于负载均衡的路由分发方法及系统 | |
| CN112073234A (zh) | 一种故障检测方法、装置、系统、设备及存储介质 | |
| CN113472670B (zh) | 用于计算机网络的方法、网络装置及存储介质 | |
| US8719633B2 (en) | Search device, search method, and search program | |
| Ranjitha et al. | A case for cross-domain observability to debug performance issues in microservices | |
| Zhang et al. | Chat: Accurate network latency measurement for 5g e2e networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40036252 Country of ref document: HK |
|
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |