CN113381895A - 网络故障的检测方法及装置 - Google Patents

网络故障的检测方法及装置 Download PDF

Info

Publication number
CN113381895A
CN113381895A CN202110663947.0A CN202110663947A CN113381895A CN 113381895 A CN113381895 A CN 113381895A CN 202110663947 A CN202110663947 A CN 202110663947A CN 113381895 A CN113381895 A CN 113381895A
Authority
CN
China
Prior art keywords
memory array
memory
network
physical port
residual quantity
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
Application number
CN202110663947.0A
Other languages
English (en)
Other versions
CN113381895B (zh
Inventor
汤永翔
王蓬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou DPTech Technologies Co Ltd
Original Assignee
Hangzhou DPTech Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou DPTech Technologies Co Ltd filed Critical Hangzhou DPTech Technologies Co Ltd
Priority to CN202110663947.0A priority Critical patent/CN113381895B/zh
Publication of CN113381895A publication Critical patent/CN113381895A/zh
Application granted granted Critical
Publication of CN113381895B publication Critical patent/CN113381895B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开涉及一种网络故障的检测方法、装置、电子设备及计算机可读介质。该方法包括:按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。本公开涉及的网络故障的检测方法、装置、电子设备及计算机可读介质,能够对网络设备出现不可自动恢复的内存缓存泄露的故障原因进行识别,并自动进行网络故障恢复。

Description

网络故障的检测方法及装置
技术领域
本公开涉及计算机信息处理领域,具体而言,涉及一种网络故障的检测方法、装置、电子设备及计算机可读介质。
背景技术
通常网络设备为了提高报文并发处理效率,系统在注册物理接口时会给每个接口预分配一块连续的内存缓存,用来缓存从硬件接收到的skb,这个内存缓存通常称之为硬Buff。每个接口的硬Buff能够缓存skb个数存在有固定上限,当硬buff中缓存的skb数量达到上限时就不能继续缓存skb报文。在正常状态下,网络设备的内核从硬件接收到skb后,会先将skb保存在硬buff缓存中,然后内核对skb进行审计、镜像、NAT、转发等业务处理,根据处理结果释放该skb对应的内存缓存空间。可能根据查找到的出接口将skb转发出去,还可能在skb为非法报文,直接将其丢弃,不管怎样,处理之后会重新释放skb占用的缓存空间,硬buff就可以继续缓存其他从硬件接收到的skb。
当系统某个业务流程出现软件bug时,可能会导致处理完的skb所占用的空间没有得到释放,在这种情况时,会导致硬buff内存持续减少,当剩余硬buff数量减少到0后,会导致硬件处无法继续缓存报文,此时会导致网络中断。通常软件bug导致的硬buff泄露系统无法自动恢复,只能通过重启系统恢复硬buff。
当遇到网络报文突增的情况,内核从硬件中接收到skb速率超过设备处理skb速率(即超过网络设备的性能时),此时如果硬buff剩余数量减少到0也会导致硬件无法继续缓存报文,出现网络中断。这种情况的硬buff泄露导致网络中断,会随着网络报文中的skb数量下降而恢复。但是事后通常需要比较有经验的网络管理员专门针对是否是网络突增导致的硬buff数量不足的问题进行排查,然后进行调整。
上述的情况给系统的使用者和维护人员带来了极大的不方便,因此,需要一种新的网络故障的检测方法、装置、电子设备及计算机可读介质。
在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解,因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
有鉴于此,本公开提供一种网络故障的检测方法、装置、电子设备及计算机可读介质,能够对网络设备出现不可自动恢复的内存缓存泄露的故障原因进行识别,并自动进行网络故障恢复。
本公开的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本公开的实践而习得。
根据本公开的一方面,提出一种网络故障的检测方法,该方法包括:按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。
在本公开的一种示例性实施例中,还包括:根据网络设备当前的整机流量确定所述预定时间周期。
在本公开的一种示例性实施例中,根据网络设备当前的整机流量确定所述预定时间周期,包括:设定初始时间周期;按照初始时间周期获取所述网络设备当前的整机流量;在所述整机流量大于等于流量阈值时,延长所述初始时间周期以生成所述预定时间周期;在所述整机流量大于流量阈值时,缩短所述初始时间周期以生成所述预定时间周期。
在本公开的一种示例性实施例中,还包括:基于所述网络设备的物理端口的总数生成所述第一内存数组和所述第二内存数组;其中,所述第一内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值的次数;所述第二内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值后又恢复正常的次数。
在本公开的一种示例性实施例中,基于所述网络设备的物理端口的总数生成所述第一内存数组和所述第二内存数组,包括:基于所述网络设备的物理端口的总数确定所述第一内存数组和所述第二内存数组的容量;申请连续的两组容量以生成所述第一内存数组和所述第二内存数组。
在本公开的一种示例性实施例中,在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组,包括:在物理端口的内存缓存的剩余数量小于告警阈值时,将所述物理端口对应的第一数组中的计数加1,同时将所述物理端口对应的第二数组中的计数清零。
在本公开的一种示例性实施例中,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组,包括:在物理端口的内存缓存的剩余数量大于等于告警阈值时,将所述物理端口对应的第一数组中的计数加清零,同时将所述物理端口对应的第二数组中的计数加1。
在本公开的一种示例性实施例中,根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因,包括:在所述第一内存数组中的物理端口对应的数量大于等于计数阈值时,确定当前处于内存缓存不足状态,生成告警信息。
在本公开的一种示例性实施例中,根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因,还包括:在生成告警信息之后,获取所述物理端口中所有内存缓存的生成时间;在所述生成时间和当前系统时间大于时间阈值时,确定所述物理端口存在内存缓存泄漏;对所述网络设备的进行重启。
在本公开的一种示例性实施例中,包括:在所述第二内存数组中的物理端口对应的数量小于计数阈值时,确定内存缓存充足,生成恢复信息。
根据本公开的一方面,提出一种网络故障的检测装置,可应用于网络设备,该装置包括:获取模块,用于按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;第一更新模块,用于在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;第二更新模块,用于在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;故障模块,用于根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。
在本公开的一种示例性实施例中,还包括:定时模块,用于根据网络设备当前的整机流量确定所述预定时间周期。
根据本公开的一方面,提出一种电子设备,该电子设备包括:一个或多个处理器;存储装置,用于存储一个或多个程序;当一个或多个程序被一个或多个处理器执行,使得一个或多个处理器实现如上文的方法。
根据本公开的一方面,提出一种计算机可读介质,其上存储有计算机程序,该程序被处理器执行时实现如上文中的方法。
根据本公开的网络故障的检测方法、装置、电子设备及计算机可读介质,按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因的方式,能够对网络设备出现不可自动恢复的内存缓存泄露的故障原因进行识别,并自动进行网络故障恢复。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性的,并不能限制本公开。
附图说明
通过参照附图详细描述其示例实施例,本公开的上述和其它目标、特征及优点将变得更加显而易见。下面描述的附图仅仅是本公开的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是根据一示例性实施例示出的一种网络故障的检测方法的流程图。
图2是根据一示例性实施例示出的一种网络故障的检测方法的流程图。
图3是根据另一示例性实施例示出的一种网络故障的检测方法的流程图。
图4是根据另一示例性实施例示出的一种网络故障的检测方法的流程图。
图5是根据一示例性实施例示出的一种网络故障的检测装置的框图。
图6是根据一示例性实施例示出的一种电子设备的框图。
图7是根据一示例性实施例示出的一种计算机可读介质的框图。
具体实施方式
现在将参考附图更全面地描述示例实施例。然而,示例实施例能够以多种形式实施,且不应被理解为限于在此阐述的实施例;相反,提供这些实施例使得本公开将全面和完整,并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。
此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中,提供许多具体细节从而给出对本公开的实施例的充分理解。然而,本领域技术人员将意识到,可以实践本公开的技术方案而没有特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。
附图中所示的方框图仅仅是功能实体,不一定必须与物理上独立的实体相对应。即,可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明,不是必须包括所有的内容和操作/步骤,也不是必须按所描述的顺序执行。例如,有的操作/步骤还可以分解,而有的操作/步骤可以合并或部分合并,因此实际执行的顺序有可能根据实际情况改变。
应理解,虽然本文中可能使用术语第一、第二、第三等来描述各种组件,但这些组件不应受这些术语限制。这些术语乃用以区分一组件与另一组件。因此,下文论述的第一组件可称为第二组件而不偏离本公开概念的教示。如本文中所使用,术语“及/或”包括相关联的列出项目中的任一个及一或多者的所有组合。
本领域技术人员可以理解,附图只是示例实施例的示意图,附图中的模块或流程并不一定是实施本公开所必须的,因此不能用于限制本公开的保护范围。
图1是根据一示例性实施例示出的一种网络故障的检测方法的流程图。网络故障的检测方法10至少包括步骤S102至S108。
如图2所示,在S102中,按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量。可例如,根据网络设备当前的整机流量确定所述预定时间周期。
在系统内核中启动一个定时器,每间隔timer_t的时间执行一次端口扫描任务,获取各个端口的内存缓存(硬buff)的剩余数量。其中,预定时间周期timer_t可基于退避算法生成,基于退避算法生成预定时间间隔的方式,可避免定时器周期太短,导致的太多次的扫描设备端口带来的过度消耗设备性能的问题,也能避免定时器周期太长,导致的不容易监控到硬buff不足的问题。
在S104中,在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组。
可例如,所述网络设备的物理端口的总数生成所述第一内存数组arry1和所述第二内存数组arry2;其中,所述第一内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值的次数;所述第二内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值后又恢复正常的次数。
可例如,在物理端口的内存缓存的剩余数量小于告警阈值时,将所述物理端口对应的第一数组中的计数加1,同时将所述物理端口对应的第二数组中的计数清零。
在S106中,在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组。
可例如,在物理端口的内存缓存的剩余数量大于等于告警阈值时,将所述物理端口对应的第一数组中的计数加清零,同时将所述物理端口对应的第二数组中的计数加1。
在S108中,根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。
可例如,在所述第一内存数组中的物理端口对应的数量大于等于计数阈值时,确定当前处于内存缓存不足状态,生成告警信息。更具体的,可在硬buff剩余数量小于告警阈值时,将当前接口对应array1中的数值加1,将当前接口对应array2中的数值清零,同时判断当前接口对应array1中的数值是否达到10次。若已达到10次,则表示当前接口已经连续10次周期内剩余硬buff都处于不足的状态,此时生成硬buff不足的告警日志以便维护人员及时处理。
在一个实施例中,在生成告警信息之后,获取所述物理端口中所有内存缓存的生成时间;在所述生成时间和当前系统时间大于时间阈值时,确定所述物理端口存在内存缓存泄漏;对所述网络设备进行重启。还可例如,系统内核从硬件中接收skb保存到硬buff时,记录收到skb时的系统时间skb_time。更具体的,发送完硬buff不足的告警信息后,遍历获取硬buff中保存的所有skb的skb_time,判断skb_time与当前系统时间的时间间隔是否超过预设值的阈值,例如100s,通常情况skb在网络设备的业务处理流程耗时很小,如果skb长时间没有被释放则表明该skb处理存在异常,即当前设备存在硬buff泄露bug;此时为了避免设备因为软件bug导致硬buff不足而长时间处于网络中断的状态,则触发系统重启流程,系统重启后硬buff自动恢复正常。
可例如,在所述第二内存数组中的物理端口对应的数量小于计数阈值时,确定内存缓存充足,生成恢复信息。更具体的,当硬buff剩余数量大于告警阈值,则将当前接口对应array1中的数值清零,并将当前接口对应array2中的数值加1,同时判断当前接口对应array2中的数值是否达到10次;若已达到10次,则表示当前接口已经连续10次周期内剩余硬buff都超过最小阈值,则发送硬buff剩余数量恢复正常的恢复信息。
根据本公开的网络故障的检测方法,按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因的方式,能够对网络设备出现不可自动恢复的内存缓存泄露的故障原因进行识别,并自动进行网络故障恢复。
图2是根据一示例性实施例示出的一种网络故障的检测方法的流程图。网络故障的检测方法20是对“根据网络设备当前的整机流量确定所述预定时间周期”的详细描述。
如图2所示,在S202中,设定初始时间周期。初始时间周期timer_t可采用退避算法生成,采用退避算法生成预定时间间隔的方式,可避免定时器周期太短,导致的太多次的扫描设备端口带来的过度消耗设备性能的问题,也能避免定时器周期太长,导致的不容易监控到硬buff不足的问题。
在S204中,按照初始时间周期获取所述网络设备当前的整机流量。定时获取网络设备当前的整机流量。
在S206中,在所述整机流量大于等于流量阈值时,延长所述初始时间周期以生成所述预定时间周期。可例如,timer_t初始值为20s,当定时器触发时,判断整机流量是否大于流量阈值,大于则将timer_t加1s,即下次间隔21s才会触发定时器。
在S208中,在所述整机流量大于流量阈值时,缩短所述初始时间周期以生成所述预定时间周期。整机流量小于流量阈值,则将timer_t减1s,即下次间隔19s就会触发定时器。
在一个具体的实施例中,还可设定预设时间间隔的范围,可例如,timer_t最大不超过30,最小不小于10。当整机流量比较大时,此时如果定时器频繁触发则会导致消耗较多的性能,并且在整机流量比较大时,可认为此时硬buff工作正常,可正常处理较大流量,这个情况下没有频繁检测的必要,所以可以延长检测时间。当整机流量比较小时,此时设备CPU比较空闲,另外,也有可能是由于硬buff泄露导致能够使用的硬buff不足,进而导致整机流量下降,因此,在这种情况下应该需要提高定时的检测频率。
根据本公开的网络故障的检测方法,采用退避算法设置定时器检测周期,避免在设备流量大时过多占用设备性能,同时当设备空闲时,提高检测频率快速发现是否由于硬buff不足导致网络异常。
应清楚地理解,本公开描述了如何形成和使用特定示例,但本公开的原理不限于这些示例的任何细节。相反,基于本公开公开的内容的教导,这些原理能够应用于许多其它实施例。
图3是根据另一示例性实施例示出的一种网络故障的检测方法的流程图。图3所示的流程30是“第一内存数组和第二内存数组”的详细描述。
如图3所示,在S302中,基于所述网络设备的物理端口的总数确定所述第一内存数组和所述第二内存数组的容量。第一内存数组和所述第二内存数组的容量相等,每个单位存储位置用于存储一个物理端口的信息。
在S304中,申请连续的两组容量以生成所述第一内存数组和所述第二内存数组。基于网络设备当前物理口总数申请两块连续的内存数组array1、array2。
在S306中,所述第一内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值的次数。
在S308中,所述第二内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值后又恢复正常的次数。
图4是根据另一示例性实施例示出的一种网络故障的检测方法的流程图。图4所示的流程40是对图2所示流程的详细描述。
如图4所示,在S401中,触发定时器检测整机流量。
在S402中,根据整机流量确定下次定时器触发的时间。
在S403中,遍历每个端口获取其剩余内存缓存的数量。定时器触发后,遍历获取所有物理口的硬buff剩余总数,判断每个接口的剩余硬buff总数是否小于告警阈值,告警阈值可例如为100,即为,当剩余硬buff总数小于100则表示剩余数量不足,当剩余硬buff总数大于等于100,则表示硬buff剩余总数正常。
在S404中,是否小于告警阈值。
在S405中,该接口对应的第一内存数组加1。
在S406中,该接口对应的第二内存数组清零。
在S407中,第一内存数组是否大于计数阈值。计数阈值可为10。
在S408中,生成告警信息。若已达到10次,则表示当前接口已经连续10次周期内剩余硬buff都处于不足的状态。生成硬buff不足的告警信息。
若未达到10次,则在网络设备的内核中保存当前接口硬buff剩余数量不足的异常信息,该异常信息可以包含当前系统时间、接口名称、剩余硬buff数量、当前系统会话排行等有用信息,可以通过show hbuff log命令查看相关信息,系统保存相关异常信息后继续等待下一个定时器扫描周期。
在S409中,是否有内存缓存泄露。发送完硬buff不足的告警日志后,遍历获取硬buff中保存的所有skb的skb_time,判断skb_time与当前系统时间的时间间隔是否超过预设值的阈值,例如100s,通常情况skb在网络设备的业务处理流程耗时很小,如果skb长时间没有被释放则表明该skb处理存在异常,即当前设备存在硬buff泄露bug。
在S410中,系统重启。此时为了避免设备因为软件bug导致硬buff不足而长时间处于网络中断的状态,触发系统重启流程,系统重启后硬buff自动恢复正常。
在S411中,该接口对应的第二内存数组加1。
在S412中,该接口对应的第一内存数组清零。
在S413中,第二内存数组是否大于计数阈值。
在S414中,生成恢复信息。若已达到10次,则表示当前接口已经连续10次周期内剩余硬buff都超过最小阈值,则发送硬buff剩余数量恢复正常的恢复信息;
若未达到10次,则继续等待下一个定时器扫描周期。
本公开的网络故障的检测方法,可以识别由于软件缺陷导致网络设备出现不可自动恢复的硬buff泄露并且自动恢复正常。
本公开的网络故障的检测方法,可以识别由于网络报文突增导致网络设备出现可以自动恢复的硬buff泄露并且自动告警的方法,并且保存相关异常信息可以方便网络管理员快速排查是否由于硬buff不足导致网络故障。
本公开的网络故障的检测方法,在连续多次内存不足时,才会发送对应硬buff不足告警信息和硬buff恢复信息的方式,可避免网络震荡时频繁发送日志对日志服务器造成负担和对用户造成困扰。
根据本公开的网络故障的检测方法,在发生硬buff不足,但是没有发现内存泄露也没有触发告警日志时,自动记录异常信息,通过show hbuff log查看异常信息,方便网络管理员快速排查是否由于硬buff不足导致网络故障。
本领域技术人员可以理解实现上述实施例的全部或部分步骤被实现为由CPU执行的计算机程序。在该计算机程序被CPU执行时,执行本公开提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中,该存储介质可以是只读存储器,磁盘或光盘等。
此外,需要注意的是,上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明,而不是限制目的。易于理解,上述附图所示的处理并不表明或限制这些处理的时间顺序。另外,也易于理解,这些处理可以是例如在多个模块中同步或异步执行的。
下述为本公开装置实施例,可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节,请参照本公开方法实施例。
图5是根据一示例性实施例示出的一种网络故障的检测装置的框图。如图5所示,网络故障的检测装置50包括:获取模块502,第一更新模块504,第二更新模块506,故障模块508,定时模块510。
获取模块502用于按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;可例如,根据网络设备当前的整机流量确定所述预定时间周期。
第一更新模块504用于在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;可例如,在物理端口的内存缓存的剩余数量小于告警阈值时,将所述物理端口对应的第一数组中的计数加1,同时将所述物理端口对应的第二数组中的计数清零。
第二更新模块506用于在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;可例如,在物理端口的内存缓存的剩余数量大于等于告警阈值时,将所述物理端口对应的第一数组中的计数加清零,同时将所述物理端口对应的第二数组中的计数加1。
故障模块508用于根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。可例如,在所述第一内存数组中的物理端口对应的数量大于等于计数阈值时,确定当前处于内存缓存不足状态,生成告警信息。可例如,在所述第二内存数组中的物理端口对应的数量小于计数阈值时,确定内存缓存充足,生成恢复信息。
定时模块510用于根据网络设备当前的整机流量确定所述预定时间周期。可例如,设定初始时间周期;按照初始时间周期获取所述网络设备当前的整机流量;在所述整机流量大于等于流量阈值时,延长所述初始时间周期以生成所述预定时间周期;在所述整机流量大于流量阈值时,缩短所述初始时间周期以生成所述预定时间周期。
根据本公开的网络故障的检测装置,按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因的方式,能够对网络设备出现不可自动恢复的内存缓存泄露的故障原因进行识别,并自动进行网络故障恢复。
图6是根据一示例性实施例示出的一种电子设备的框图。
下面参照图6来描述根据本公开的这种实施方式的电子设备600。图6显示的电子设备600仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图6所示,电子设备600以通用计算设备的形式表现。电子设备600的组件可以包括但不限于:至少一个处理单元610、至少一个存储单元620、连接不同系统组件(包括存储单元620和处理单元610)的总线630、显示单元640等。
其中,所述存储单元存储有程序代码,所述程序代码可以被所述处理单元610执行,使得所述处理单元610执行本说明书中描述的根据本公开各种示例性实施方式的步骤。例如,所述处理单元610可以执行如图1至图4中所示的步骤。
所述存储单元620可以包括易失性存储单元形式的可读介质,例如随机存取存储单元(RAM)6201和/或高速缓存存储单元6202,还可以进一步包括只读存储单元(ROM)6203。
所述存储单元620还可以包括具有一组(至少一个)程序模块6205的程序/实用工具6204,这样的程序模块6205包括但不限于:操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。
总线630可以为表示几类总线结构中的一种或多种,包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
电子设备600也可以与一个或多个外部设备600’(例如键盘、指向设备、蓝牙设备等)通信,使得用户能与该电子设备600交互的设备通信,和/或该电子设备600能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且,电子设备600还可以通过网络适配器660与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。网络适配器660可以通过总线630与电子设备600的其它模块通信。应当明白,尽管图中未示出,可以结合电子设备600使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,如图7所示,根据本公开实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、或者网络设备等)执行根据本公开实施方式的上述方法。
所述软件产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质,该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、有线、光缆、RF等等,或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算设备,或者,可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该设备执行时,使得该计算机可读介质实现如下功能:按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。
本领域技术人员可以理解上述各模块可以按照实施例的描述分布于装置中,也可以进行相应变化唯一不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
通过以上的实施例的描述,本领域的技术人员易于理解,这里描述的示例实施例可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本公开实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施例的方法。
以上具体地示出和描述了本公开的示例性实施例。应可理解的是,本公开不限于这里描述的详细结构、设置方式或实现方法;相反,本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (12)

1.一种网络故障的检测方法,可应用于网络设备,其特征在于,包括:
按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;
在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;
在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;
根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。
2.如权利要求1所述的方法,其特征在于,还包括:
根据网络设备当前的整机流量确定所述预定时间周期。
3.如权利要求2所述的方法,其特征在于,根据网络设备当前的整机流量确定所述预定时间周期,包括:
设定初始时间周期;
按照初始时间周期获取所述网络设备当前的整机流量;
在所述整机流量大于等于流量阈值时,延长所述初始时间周期以生成所述预定时间周期;
在所述整机流量大于流量阈值时,缩短所述初始时间周期以生成所述预定时间周期。
4.如权利要求1所述的方法,其特征在于,还包括:
基于所述网络设备的物理端口的总数生成所述第一内存数组和所述第二内存数组;
其中,所述第一内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值的次数;所述第二内存数组用于记录每个物理端口的内存缓存的剩余数量小于告警阈值后又恢复正常的次数。
5.如权利要求4所述的方法,其特征在于,基于所述网络设备的物理端口的总数生成所述第一内存数组和所述第二内存数组,包括:
基于所述网络设备的物理端口的总数确定所述第一内存数组和所述第二内存数组的容量;
申请连续的两组容量以生成所述第一内存数组和所述第二内存数组。
6.如权利要求1所述的方法,其特征在于,在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组,包括:
在物理端口的内存缓存的剩余数量小于告警阈值时,将所述物理端口对应的第一数组中的计数加1,同时将所述物理端口对应的第二数组中的计数清零。
7.如权利要求1所述的方法,其特征在于,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组,包括:
在物理端口的内存缓存的剩余数量大于等于告警阈值时,将所述物理端口对应的第一数组中的计数加清零,同时将所述物理端口对应的第二数组中的计数加1。
8.如权利要求1所述的方法,其特征在于,根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因,包括:
在所述第一内存数组中的物理端口对应的数量大于等于计数阈值时,确定当前处于内存缓存不足状态,生成告警信息。
9.如权利要求8所述的方法,其特征在于,根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因,还包括:
在生成告警信息之后,获取所述物理端口中所有内存缓存的生成时间;
在所述生成时间和当前系统时间大于时间阈值时,确定所述物理端口存在内存缓存泄漏;
对所述网络设备的进行重启。
10.如权利要求1所述的方法,其特征在于,根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因,包括:
在所述第二内存数组中的物理端口对应的数量小于计数阈值时,确定内存缓存充足,生成恢复信息。
11.一种网络故障的检测装置,可应用于网络设备,其特征在于,包括:
获取模块,用于按照预定时间周期定时获取设备的各个物理端口对应的内存缓存的剩余数量;
第一更新模块,用于在剩余数量小于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第一规则更新第一内存数组和第二内存数组;
第二更新模块,用于在剩余数量大于等于告警阈值时,基于各个物理端口对应的内存缓存的剩余数量按照第二规则更新第一内存数组和第二内存数组;
故障模块,用于根据所述第一内存数组和所述第二内存数组记录的数据确定当前的网络的故障原因。
12.如权利要求1所述的装置,其特征在于,还包括:
定时模块,用于根据网络设备当前的整机流量确定所述预定时间周期。
CN202110663947.0A 2021-06-16 2021-06-16 网络故障的检测方法及装置 Active CN113381895B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110663947.0A CN113381895B (zh) 2021-06-16 2021-06-16 网络故障的检测方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110663947.0A CN113381895B (zh) 2021-06-16 2021-06-16 网络故障的检测方法及装置

Publications (2)

Publication Number Publication Date
CN113381895A true CN113381895A (zh) 2021-09-10
CN113381895B CN113381895B (zh) 2022-06-24

Family

ID=77574517

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110663947.0A Active CN113381895B (zh) 2021-06-16 2021-06-16 网络故障的检测方法及装置

Country Status (1)

Country Link
CN (1) CN113381895B (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004005305A (ja) * 2002-06-03 2004-01-08 Hitachi Ltd メモリ使用容量の監視方法及び計算機システム
WO2010043176A1 (zh) * 2008-10-17 2010-04-22 华为技术有限公司 内存泄漏的检测方法和装置
CN102955719A (zh) * 2011-08-31 2013-03-06 国际商业机器公司 疑似内存泄漏的确定方法及装置
CN106708616A (zh) * 2016-11-29 2017-05-24 深圳天珑无线科技有限公司 进程控制方法和进程控制装置
CN108052409A (zh) * 2017-12-19 2018-05-18 杭州迪普科技股份有限公司 一种skb申请信息显示方法及装置
US20210036971A1 (en) * 2019-08-01 2021-02-04 Denso Corporation Electronic control unit, abnormality determination program, and abnormality determination method
CN112948156A (zh) * 2019-12-11 2021-06-11 中兴通讯股份有限公司 内存耗尽诊断方法、装置、系统和存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004005305A (ja) * 2002-06-03 2004-01-08 Hitachi Ltd メモリ使用容量の監視方法及び計算機システム
WO2010043176A1 (zh) * 2008-10-17 2010-04-22 华为技术有限公司 内存泄漏的检测方法和装置
CN102955719A (zh) * 2011-08-31 2013-03-06 国际商业机器公司 疑似内存泄漏的确定方法及装置
CN106708616A (zh) * 2016-11-29 2017-05-24 深圳天珑无线科技有限公司 进程控制方法和进程控制装置
CN108052409A (zh) * 2017-12-19 2018-05-18 杭州迪普科技股份有限公司 一种skb申请信息显示方法及装置
US20210036971A1 (en) * 2019-08-01 2021-02-04 Denso Corporation Electronic control unit, abnormality determination program, and abnormality determination method
CN112948156A (zh) * 2019-12-11 2021-06-11 中兴通讯股份有限公司 内存耗尽诊断方法、装置、系统和存储介质

Also Published As

Publication number Publication date
CN113381895B (zh) 2022-06-24

Similar Documents

Publication Publication Date Title
CN110661659B (zh) 一种告警方法、装置、系统及电子设备
US10558545B2 (en) Multiple modeling paradigm for predictive analytics
US9191296B2 (en) Network event management
CN114328102A (zh) 设备状态监控方法、装置、设备及计算机可读存储介质
CN106682162B (zh) 日志管理方法及装置
CN109656885B (zh) 存储空间监控方法及装置、电子终端、存储介质
US20100042996A1 (en) Utilization management
US20170308423A1 (en) Mitigating Crashes of an Application Server Executing a Monitoring Agent
CN104866296A (zh) 数据处理方法和装置
CN111062503B (zh) 一种电网监控告警处理方法、系统、终端及存储介质
US8214693B2 (en) Damaged software system detection
CN110018932B (zh) 一种容器磁盘的监控方法及装置
CN113672416B (zh) 硬buffer泄漏的原因定位方法及装置
CN110780815A (zh) 日志的删除方法及装置
CN114676019A (zh) 一种中央处理器状态监测方法、装置、设备、存储介质
CN106899436A (zh) 一种云平台故障预测诊断系统
CN113884943A (zh) 漏电故障分析方法、装置、设备及介质
CN113590405A (zh) 硬盘错误的检测方法、装置、存储介质和电子装置
CN113381895B (zh) 网络故障的检测方法及装置
CN111124818B (zh) 一种扩展器Expander的监控方法、装置及设备
CN113791943A (zh) 网站实时监控方法、系统、设备及存储介质
CN115102838B (zh) 服务器宕机风险的应急处理方法和装置、电子设备
CN110851316B (zh) 异常预警方法及装置、系统、电子设备、存储介质
CN109062718B (zh) 一种服务器及数据处理方法
JP2012247937A (ja) 情報処理装置、ログ記憶制御プログラムおよびログ記憶制御方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant