一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

故障分析方法、装置、设备、存储介质和程序产品与流程

2022-11-16 09:45:32 来源:中国专利 TAG:


1.本公开的实施例主要涉及信息技术领域。更具体地,本公开的实施例涉及网卡设备的故障分析方法、装置、设备、计算机可读存储介质以及计算机程序产品。


背景技术:

2.在网卡设备出现故障时,诸如运维人员通常通过各种工具获取一系列的网络指标数据和业务运行数据,基于获取的数据以及个人的维护经验判定故障发生的地点和原因。随着系统数据、故障告警以及网络数据的日益增加,对目前的运维机制形成巨大挑战。


技术实现要素:

3.为了实现网卡设备的故障分析自动化,本公开的实施例提供了一种用于分析网卡设备故障的方案。
4.在本公开的第一方面,提供了故障分析方法。该方法包括:获取网卡设备的待分析数据;如果确定待分析数据满足故障判定条件,确定因果关系信息中的与故障判定条件相对应的叶子节点,该因果关系信息用于分析网卡设备的故障,并且因果关系信息中的每个因果关系节点指示网卡设备的一个故障;确定因果关系信息中的、叶子节点的关联节点,所述叶子节点和所述关联节点均是因果关系信息中的因果关系节点;以及基于关联节点指示的故障,确定针对网卡设备的故障分析结果。
5.本公开对网卡设备的各待分析数据与因果关系信息中的叶子节点的故障进行关联,从而可以基于待分析数据中的某一项或多项数据来判定相应的叶子节点处指示的故障是否发生。由此,本公开可以自动检测和分析网卡设备的故障,从而解决了人工运维的诸多问题。一方面,本公开提出的故障检测过程可以遍历所有可能发生的故障,从而可以提升故障检测过程的准确性和全面性。另一方面,当确定了与故障对应的叶子节点之后,本公开进一步基于因果关系信息来推导上述叶子节点的上层关联节点,从而可以准确确定网卡设备发生故障的根因。因此,本公开的故障推导过程简化了诸如运维人员的用户的故障排查难度,减少了故障排查时间。
6.在第一方面的一种实现方式中,可以由用户或者计算单元获取网卡设备的待分析数据。之后,可以由计算单元判定待分析数据是否满足故障判定条件,如果待分析数据满足故障判定条件,计算单元可以确定因果关系信息中的与故障判定条件相对应的叶子节点。进而,计算单元可以确定因果关系信息中的、叶子节点的关联节点,并且基于关联节点指示的故障,自动确定和输出针对网卡设备的故障分析结果。由于待分析数据通常具有可观的数据量,本公开可以利用计算单元来对待分析数据进行监控,从而可以及时准确地确定故障分析结果,且无需人工干预。
7.在第一方面的一种实现方式中,所述因果关系节点还包括附加叶子节点,所述关联节点是所述叶子节点和附加叶子节点的上层节点,并且确定关联节点可以包括:基于所述因果关系信息确定所述叶子节点与所述附加叶子节点之间的逻辑关系;如果确定所述逻
辑关系为或,计算单元可以基于叶子节点确定关联节点。也就是说,当确定叶子节点与附加叶子节点之间存在或的逻辑关系时,由于确定了该叶子节点的故障,故可以直接确定作为其上层节点的关联节点。另外,如果确定所述逻辑关系为与,计算单元可以进一步确定待分析数据是否满足与附加叶子节点对应的故障判定条件,如果是,则可以基于该叶子节点和该附加叶子节点确定作为其上层节点的关联节点。也就是说,仅当两个叶子节点均满足相应的故障判定条件,则可以向上推导出关联节点。通过限定“或”和“与”的逻辑关系,可以提高上层关联节点的推导精度,丰富故障树的多样性,提升故障分析的准确性。
8.在第一方面的一种实现方式中,关联节点可以包括因果关系信息中的根节点、以及叶子节点与根节点之间的至少一个节点。换言之,可以将多个故障节点进行分层,从而可以实现故障的逐层推导,由此可以提升故障推导的准确性,且降低了推导难度。
9.在第一方面的一种实现方式中,至少基于所述关联节点指示的故障确定所述故障分析结果包括:基于所述关联节点指示的第一故障以及所述叶子节点指示的第二故障,确定故障图,所述故障图中包含所述第一故障、所述第二故障,以及所述第一故障和所述第二故障的因果关系;以及将所述故障图确定为所述故障分析结果。通过以故障图的形式向用户展示故障分析结果,可以是用户更为直观的了解各故障节点之间的关联关系,从而可以对故障进行更全面的分析。
10.在第一方面的一种实现方式中,该方法还可以包括:将所述故障分析结果与实际分析结果进行比较,所述实际分析结果是由用户确定的;以及如果所述故障分析结果与所述实际分析结果不同,将所述实际分析结果应用于判定条件更新模型,以确定更新后的所述故障判定条件,其中所述判定条件更新模型是基于训练数据集来训练得到的,所述训练数据集包含参考分析结果以及经标记的参考故障判定条件。以此方式,可以在计算单元确定的故障分析结果不令人满意时,基于实际分析结果来更新故障判定条件,从而使后续的故障分析结果更准确。
11.在第一方面的一种实现方式中,故障判定条件可以包括以下至少一项:网卡设备的网关环回短包丢包数大于第一阈值数目;网卡设备的网关短包环回响应时间大于第一阈值响应时间;网卡设备的网关环回长包丢包数大于第二阈值数目;网卡设备的网关长包环回响应时间大于第二阈值响应时间;网卡设备的链路环回短包丢包数大于第三阈值数目;网卡设备的链路短包环回响应时间大于第三阈值响应时间;网卡设备的链路环回长包丢包数大于第四阈值数目;以及网卡设备的链路长包环回响应时间大于第四阈值响应时间。通过详细定义有关环回异常故障的所有故障分类的判定条件,可以实现自动且精细的故障判定。
12.在第一方面的一种实现方式中,上述故障判定条件被预先加载到计算单元的故障判定模块中。该故障判定条件可以是用户预先编写的配置文件,该配置文件包含多个特定的故障判定条件,这些故障判定条件与网卡设备的具体故障相对应。
13.在第一方面的一种实现方式中,可以接收用户基于经验或历史数据预先确定的多个特定故障和相应的故障判定条件,并且基于特定故障和相应的故障判定条件对故障判定条件的配置文件进行定期优化。以此方式,可以保证故障判定条件被准确设置,从而实现准确的故障分析。
14.在第一方面的一种实现方式中,该故障分析方法还可以包括:将故障分析结果与
实际分析结果进行比较,实际分析结果是由用户确定的;以及如果故障分析结果与实际分析结果不同,将实际分析结果应用于判定条件更新模型,以确定更新后的所述故障判定条件,其中判定条件更新模型可以是基于训练数据集来训练得到的,所述训练数据集包含参考分析结果以及经标记的参考故障判定条件。由此,可以实现故障判定条件的优化和更新,从而可以保障故障分析结果的准确性。
15.在第一方面的一种实现方式中,因果关系信息可以是用于执行故障推导操作的故障树。故障树是树状逻辑因果关系图,利用故障树,可以系统地设置叶子节点的关联节点和上层级节点,从而可以定义较为复杂的故障联动关系。
16.在第一方面的一种实现方式中,对如下至少一项待检测数据进行检测:网卡设备的网关环回短包丢包数;网卡设备的网关短包环回响应时间;网卡设备的网关环回长包丢包数;网卡设备的网关长包环回响应时间;网卡设备的链路环回短包丢包数;网卡设备的链路短包环回响应时间;网卡设备的链路环回长包丢包数;以及网卡设备的链路长包环回响应时间。如果该至少一项待检测数据异常,则确定至少一项待检测数据满足相应故障判定条件。通过监控相关数据的异常状态,可以准确、及时地定位故障。
17.在第一方面的一种实现方式中,可以仅基于关联节点指示的故障来确定针对网卡设备的故障分析结果。基于关联节点或者至少部分关联节点指示的故障来确定故障分析结果,可以向用户、尤其是运维人员展示故障的更深层次的动因,有利于快速确定故障的解决方案。
18.在第一方面的一种实现方式中,可以基于叶子节点以及关联节点指示的故障确定故障分析结果。基于关联节点和叶子节点指示的故障来确定故障分析结果,可以向用户、尤其是运维人员展示全面的故障图,有利于故障的精准定位。
19.在第一方面的一种实现方式中,上述计算单元至少可以实现数据采集模块、故障判定模块和故障推导模块的硬件逻辑。备选地,计算单元可以通过读取存储有数据采集模块、故障判定模块和故障推导模块的软件代码并执行相应的软件代码或程序指令,以实现相应的功能。以此方式,可以自动化地确定网卡设备发生故障的原因。
20.在第一方面的一种实现方式中,待分析数据可以包括与网卡设备相关联的操作数据和/或日志数据。所述操作数据通常是指检测得到的网卡设备的性能或其他工作参数。所述日志数据通常是指网卡设备运行过程中产生的日志事件记录。以此方式,计算单元可以较为全面地监控网卡设备的工作状态,尤其可以检测出操作数据和日志数据同时出现异常才可以进行判定的故障。
21.在第一方面的一种实现方式中,故障树中的叶子节点与故障判定条件之间的映射关系可以与故障判定条件一同被加载在计算单元的故障判定模块中,或者映射关系可以被存储在计算单元的存储模块中且故障判定模块可以从该存储模块即时查询映射关系。以此方式,可以建立故障节点与故障判定条件的对应关系,从而实现自动化地故障判定,进而自动化地实现故障推导。
22.在本公开的第二方面,提供了一种用于故障分析的装置。该装置包括用于实现上述第一方面或第一方面的任意一种实现方式的功能模块。
23.在本公开的第三方面,提供了一种电子设备。该电子设备包括:至少一个计算单元;至少一个存储器,至少一个存储器被耦合到至少一个计算单元并且存储用于由至少一
个计算单元执行的指令,指令当由至少一个计算单元执行时,使得设备执行第一方面或者第一方面中的任意一种实现方式中的方法。
24.在本公开的第四方面,提供了一种计算机可读存储介质。计算机可读存储介质存储有一条或多条计算机指令,其中一条或多条计算机指令被处理器执行实现第一方面或者第一方面中的任意一种实现方式中的方法。
25.在本公开的第五方面,提供一种计算机程序产品。计算机程序产品包括计算机可执行指令,计算机可执行指令在被处理器执行时,使计算机执行第一方面或者第一方面中的任意一种实现方式中的方法的部分或全部步骤的指令。
26.可以理解地,上述提供的第二方面的用于故障分析的装置、第三方面的电子设备、第四方面的计算机存储介质或者第五方面的计算机程序产品均用于实现第一方面所提供的方法。因此,关于第一方面的解释或者说明同样适用于第二方面、第三方面、第四方面和第五方面。此外,第二方面、第三方面、第四方面和第五方面所能达到的有益效果可参考对应方法中的有益效果,此处不再赘述。
27.本发明的这些和其它方面在以下(多个)实施例的描述中会更加简明易懂。
附图说明
28.结合附图并参考以下详细说明,本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中,相同或相似的附图标注表示相同或相似的元素,其中:
29.图1示出了本公开的多个实施例能够在其中实现的示例系统的示意图;
30.图2示出了根据本公开的实施例的计算单元的示意图;
31.图3示出了根据本公开的实施例的故障树与故障判定条件的映射关系的示意图;
32.图4示出了根据本公开的实施例的用于故障分析的过程的流程图;
33.图5示出了根据本公开的一些实施例的用于故障分析的装置的示意性框图;以及
34.图6示出了能够实施本公开的多个实施例的计算单元的框图。
具体实施方式
35.下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例,然而应当理解的是,本公开可以通过各种形式来实现,而且不应该被解释为限于这里阐述的实施例,相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是,本公开的附图及实施例仅用于示例性作用,并非用于限制本公开的保护范围。
36.在本公开的实施例的描述中,术语“包括”及其类似用语应当理解为开放性包含,即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。此外,在本文中,“和/或”用于表示多个对象中的至少一个对象。例如,“a和/或b”表示“a”、“b”以及“a和b”三种情况中的一种情况。
37.如上文所讨论的,随着系统数据、故障告警以及网络数据的日益增加,传统的依靠人工方式的运维机制存在工作量巨大、故障定位时间长的缺点,已经无法满足网络系统的日常需求。此外,由于网络故障尤其是网卡设备故障的种类繁多,用户需要丰富的运维经验和技术功底,这使得网络运维工作的技术门槛较高。
38.为了解决人工运维的上述诸多问题,实现网卡设备的故障分析自动化,本公开提供了通过故障分层方式实现对网卡设备的故障进行分析的方案。作为示例,本公开通过对各种故障模式进行分层定义,并且通过将最后一层的故障模式与实时采集的系统数据进行关联,来实现故障分析的自动化。具体地,当判定系统数据中的至少部分数据符合最后一层故障模式所对应的判定条件时,可以从最后一层故障模式向上逐层推导各层中可能存在的故障模式,从而形成完整的故障图或故障链。
39.以此方式,可以自动快速地分析并确定出各个层级的故障模式,无需诸如运维人员依靠经验进行故障推导,并且可以为用户后续的故障处理提供更为详细的参考信息。
40.为了更准确地描述本公开的构思,下面结合图1详细描述根据本公开的实施例的示例系统。
41.示例系统
42.根据本公开的各种实施例,提供了一种用于分析网卡设备故障的方案。在本公开的实施例中,首先获取网卡设备的待分析数据。备选地或附加地,还可以进一步获取因果关系信息,因果关系信息用于分析网卡设备的故障,并且因果关系信息中的每个因果关系节点可以指示网卡设备的一个故障。随后,可以通过计算单元来判定待分析数据是否满足故障判定条件。如果确定待分析数据满足因果关系信息的至少一个叶子节点相对应的故障判定条件,计算单元可以确定因果关系信息中的与该故障判定条件相对应的至少一个叶子节点。进而,可以通过计算单元确定因果关系信息中的、至少一个叶子节点的关联节点。应理解,上述叶子节点和关联节点均是因果关系信息中的因果关系节点。至少基于关联节点指示的故障,确定针对网卡设备的故障分析结果。
43.优选地,除了仅基于关联节点指示的故障,还可以基于叶子节点指示的故障确定针对网卡设备的故障分析结果。应理解,基于关联节点指示的故障确定的故障分析结果主要用于展示故障的更深层次的动因,有利于快速确定故障的解决方案;相应地,基于关联节点和叶子节点指示的故障确定的故障分析结果可以向工作人员展示全面的故障图,有利于故障的精准定位。当然,为了节约计算资源,可以仅基于关联节点中的发生概率大于阈值概率的部分关联节点来生成故障分析结果。
44.基于这样的方式,本公开的实施例可以系统地确定每一个故障以及该故障的更深层次的动因,从而能够充分地考虑网卡设备的每一种故障情形,进而基于故障树推导网卡设备的故障。此过程可以通过计算设备监控网卡设备的相关数据并在数据异常时自动确定故障原因及其根因,无需运维人员收集相关数据和了解内部故障间的关联关系并基于经验确定具体故障,从而降低了运维难度,节约了排查故障所需的时间。
45.图1示出了本公开的多个实施例能够在其中实现的示例系统100的示意图。
46.如图1所示,系统100包括源机110,网关120和目的机130。源机110可以是物理机。物理机通常是指作为实体的硬件系统,例如可以是服务器、个人计算机等硬件设备。应理解,为了实现相应计算功能,源机110可以包含诸如处理器的计算资源以及诸如存储器的存储资源。此外,如图1所示,源机110作为物理机可以包括硬件实现的网卡设备140。应理解,虽然未示出,源机110内部还可以包括操作系统/驱动模块以及用于网络交互的网络进程模块。网卡设备140用于向网关120发送数据包或者从网关120接收数据包。作为不同网络之间的连接器,网关120可以将接收到的数据包转发至目的机130,或者将来自目的机130的数据
传递至源机110。与源机类似地,目的机130也可以是物理机。应理解,源机110与网关120之间通常还设置有交换机,并且网关120通常可以经由网络连接至目的机130。
47.上文描述了源机110经由网关120与目的机130通信连接的基于物理机的常规跨网关通信部署方式。除此之外,源机110与目的机130还可以通过虚拟机-物理机通信部署方式实现通信连接。作为示例,源机110可以是虚拟机,并且目的机130可以是物理机。虚拟机通常是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的虚拟系统。如图1所示,源机110作为虚拟机可以包括虚拟的网卡设备140。网卡设备140用于向网关120发送数据包或者从网关120接收数据包。作为不同网络之间的连接器,网关120可以将接收到的数据包转发至目的机130,或者将来自目的机130的数据传递至源机110。与上文类似地,源机110与网关120之间通常还设置有交换机,并且网关120通常可以经由网络连接至目的机130。在此示例中,源机110、网关120及其间设置的交换机共同构成源机网络。由此可以实现虚拟机跨物理机的网络通信。
48.备选地,源机110与目的机130还可以通过虚拟机在物理机上的网络直连模式实现通信连接。作为示例,如图1所示,源机110可以是虚拟机,并且目的机130也是虚拟机,并且源机110和目的机130可以通过部署在同一物理机中的相应交换机和网关120进行通信。附加地,源机110与目的机130还可以通过虚拟机在物理机上的其他模式实现通信连接。作为示例,如图1所示,源机110可以是虚拟机,并且目的机130也是虚拟机,并且源机110和目的机130可以通过部署在同一物理机中的虚拟的交换机和虚拟的网关120进行通信。
49.应注意,如图1所示,系统100还可以包括计算单元150。计算单元150被配置为基于从网卡设备140获取的待分析数据来对网卡设备进行故障检测。当网卡设备140中布置有处理器或其他计算资源时,计算单元150可以被布置在网卡设备140的处理器中。此外,计算单元150还可以被布置在源机110的处理器中。备选地或附加地,计算单元150也可以被布置在云端。应理解,无论计算单元150布置在何处,计算单元150均与网卡设备140通信连接。在一些实施例中,计算单元150在被布置在云端的情况下,可以通过个人计算机、服务器计算机、手持或膝上型设备、移动设备(诸如移动电话、个人数字助理pda、媒体播放器等)、消费电子产品、小型计算机、大型计算机、云计算资源等来实现。应理解,计算单元150可以设置在用于实现故障分析的设备中或者其他用于通过故障监控实现相应功能的设备中。
50.为了便于更好地理解本公开,下文将参照图2详细介绍计算单元150的示例结构。
51.计算单元的示例结构
52.图2示出了根据本公开的实施例的计算单元150的示意图。如图2所示,计算单元150至少可以实现数据采集模块210、故障判定模块220和故障推导模块230的硬件逻辑。备选地,计算单元150可以通过读取存储有数据采集模块210、故障判定模块220和故障推导模块230的软件代码并执行相应的软件代码或程序指令,以实现相应的功能。作为示例,当计算单元150通过网卡设备140的处理器实现时,数据采集模块210、故障判定模块220和故障推导模块230可以存储在网卡设备140的存储器中,计算单元150从网卡设备140的存储器中读取数据采集模块210、故障判定模块220和故障推导模块230的软件代码或程序指令,以实现相应的功能。
53.在某些实施例中,数据采集模块210可以将从网卡设备140处获取的待分析数据240传输至故障判定模块220。作为示例,当计算单元150实现了数据采集模块210、故障判定
模块220和故障推导模块230的硬件逻辑的情况下,硬件逻辑的数据采集模块210可以与网卡设备140通信连接,以便从网卡设备140实时获取待分析数据240。如果数据采集模块210位于网卡设备140中,则数据采集模块210可以从网卡设备140的日志存储模块、或者数据传输线路中获取待分析数据240。作为另一示例,当计算单元150从网卡设备140的存储器中读取数据采集模块210、故障判定模块220和故障推导模块230的软件代码或程序指令以实现相应的功能时,计算单元150可以通过从网卡设备140的相应存储单元中读取数据采集模块210的软件代码或程序指令来实现数据采集功能,从而从网卡设备140的日志存储模块、或者数据传输线路中获取待分析数据240。
54.为了实现网卡故障的实时监控,数据采集模块210可以经由诸如数据传输路径将实时获取的待分析数据240传送至故障判定模块220。作为示例,当计算单元150实现了数据采集模块210、故障判定模块220和故障推导模块230的硬件逻辑的情况下,硬件逻辑可以实时接收网卡设备140的待分析数据240。作为另一示例,当计算单元150从网卡设备140的存储器中读取数据采集模块210、故障判定模块220和故障推导模块230的软件代码或程序指令以实现相应的功能时,计算单元150可以通过读取故障判定模块220的软件代码或程序指令来实现故障判定功能,从而对由计算单元150获取的待分析数据240进行故障判定。
55.应理解,待分析数据240可以包括与网卡设备140相关联的操作数据和/或日志数据。所述操作数据通常是指检测得到的网卡设备140的性能或其他工作参数。作为示例,所述操作数据可以是网卡设备140的网关环回短包丢包数,即,在从网卡设备140向网关120发送短包并接收返回的短包的过程中丢失的短包的数目。此外,所述日志数据通常是指网卡设备140运行过程中产生的日志事件记录。作为示例,日志数据可以是网卡设备140的连接状态为“unlink”。待分析数据240是计算单元150执行故障分析过程的基础。通过监控网卡设备的操作数据和/或日志数据,可以更全面地检测网卡设备可能出现的所有故障,尤其可以检测出操作数据和日志数据同时出现异常才可以进行判定的故障。
56.在某些实施例中,在接收到来自数据采集模块210的待分析数据240后,故障判定模块220会对待分析数据240进行故障判断处理。在某些实施例中,故障判定模块220可以逐一地或者并行地将待分析数据240中的每个或每组数据与预先加载的故障判定条件250进行比对,以确定待分析数据240中是否存在符合故障判定条件250的数据。作为示例,预先加载的故障判定条件250可以是用户预先编写的配置文件,其包含若干具体的故障判定条件,这些故障判定条件与网卡设备140的具体故障相对应。例如,用户在编写好关于故障判定条件250的配置文件后,可以将其加载至计算单元150,进而可以由计算单元150将故障判定条件250存储至相应存储模块。备选地,用户可以将编写好的关于故障判定条件250的配置文件直接存储至相应存储模块,以备计算单元150调用其中的故障判定条件250。由此,故障判定模块220可以经由诸如总线的数据传输路径从存储模块中获取最新版本的故障判定条件250,以便对待分析数据240进行故障判定。应理解,故障判定条件250中的多个故障判定条件以及相关联的具体故障可以是用户预先确定的。例如,计算单元150可以接收用户基于经验或历史数据预先确定的多个具体故障和相应的故障判定条件,并且基于这些具体故障和相应的故障判定条件按照预定策略对故障判定条件250的配置文件进行定期优化。故障判定条件250的优化过程将在下文详细描述。
57.由此,如果故障判定模块220确定待分析数据240满足故障判定条件250中的某个
判定条件,则可以确定与该判定条件相对应的故障节点,作为叶子节点信息260。进而,故障推导模块230可以基于确定的叶子节点信息260以及预先加载的故障树270进一步确定该故障节点在故障树270中的关联节点。应理解,本公开在进行故障推导时不限于使用故障树270,还可以使用数据结构类型的查找表。作为示例,应理解,故障树270中的每个节点可以用于指示网卡设备140的一个故障。由此,计算单元150可以基于检测到的一个或多个具体故障、和预先加载的故障树270推导出指示更高层级的故障的关联节点。计算单元150可以基于该关联节点指示的故障,输出针对网卡设备140的故障分析结果280。
58.为了便于更好地理解本公开,下文将参照图3详细描述加载在故障推导模块230处的故障树270的示例结构。
59.故障树与故障判定条件的示例结构
60.图3示出了根据本公开的实施例的故障树270与故障判定条件250的映射关系300的示意图。应理解,映射关系300可以与故障判定条件250一同被加载在故障判定模块220中,或者映射关系300可以被存储在计算单元150的存储模块中且故障判定模块220可以从该存储模块即时查询映射关系300。
61.如图3所示,故障树270可以包含位于多个层级的节点。作为示例,故障树270可以包含根层级节点(通常为单一节点,例如图3中的“网卡传输故障”节点)271、多个高层级节点272、多个中层级节点273以及多个叶子节点274。根层级节点271可以表示相应故障类型的最大分类。作为示例,当网卡设备140被确定为被监控的对象时,网卡设备140的故障类型的最大分类可以是“网卡传输故障”。多个高层级节点272作为故障类型的最大分类的下游分支,可以包含若干更为详细的故障分类。例如,“网卡传输故障”的根层级节点271可以包含诸如“环回异常”、“缓冲区故障”、“错误报文过多”、“报文短包过多”、“网络带宽过载”、“网卡配置错误”、“驱动异常”的多个高层级节点272。
62.相应地,高层级节点272可以进一步具有更为详细的故障分类。如图3所示,作为高层级节点272的“环回异常”节点可以对应于作为中层级节点273的“网关环回异常”节点以及“目的机环回异常”节点。作为高层级节点272的“缓冲区故障”节点可以对应于作为中层级节点273的“接收缓冲区异常”节点以及“发送缓冲区异常”节点。作为高层级节点272的“错误报文过多”节点可以对应于作为中层级节点273的“接收报文错误过多”节点以及“发送报文错误过多”节点。
63.应理解,高层级节点272的下游节点除了中层级节点273外,还可以包含部分叶子节点273。如图3所示,作为高层级节点272的“报文短包过多”节点可以对应于作为叶子节点274的“接收报文短包过多”节点以及“发送报文短包过多”节点。作为高层级节点272的“网络带宽过载”节点可以对应于作为叶子节点274的“接收网络带宽过载”节点以及“发送网络带宽过载”节点。作为高层级节点272的“网卡配置错误”节点可以对应于作为叶子节点274的“工作状态故障”节点以及“网速自适应配置异常”节点。作为高层级节点272的“驱动异常”节点可以对应于作为叶子节点274的“驱动版本不匹配”节点。
64.相应地,中层级节点273可以进一步具有更为详细的故障分类。如图3所示,作为中层级节点273的“网关环回异常”(即,数据包从源机110到网关120再返回源机110的过程中出现异常)节点可以对应于作为叶子节点274的“短报文丢包”节点、“短报文响应时间过长”节点、“长报文丢包”节点以及“长报文响应时间过长”节点。作为中层级节点273的“目的机
环回异常”(即,数据包从源机110到目的机130再返回源机110的过程中出现异常)节点可以对应于作为叶子节点274的“短报文丢包”节点、“短报文响应时间过长”节点、“长报文丢包”节点以及“长报文响应时间过长”节点。作为中层级节点273的“接收缓冲区异常”节点可以对应于作为叶子节点274的“接收报文异常丢弃”节点和“接收溢出错误”节点。作为中层级节点273的“发送缓冲区异常”节点可以对应于作为叶子节点274的“发送报文异常丢弃”节点和“发送溢出错误”节点。作为中层级节点273的“接收报文错误过多”节点可以对应于作为叶子节点274的“接收错误报文过多”节点和“接收帧错误过多”节点。作为中层级节点273的“发送报文错误过多”节点可以对应于作为叶子节点274的“发送错误报文过多”节点、“发送冲撞报文过多”节点以及“发送载波错误过多”节点。
65.应理解,通过查询映射关系300,每个叶子节点274分别与故障判定条件250中的相应判定条件一一对应。作为示例,叶子节点“短报文丢包”(网关)对应于判定条件“网关环回短包丢包数》0”。叶子节点“短报文响应时间过长”(网关)对应于判定条件“网关短包环回响应时间》10ms”。叶子节点“长报文丢包”(网关)对应于判定条件“网关环回长包丢包数》0”。叶子节点“长报文响应时间过长”(网关)对应于判定条件“网关长包环回响应时间》20ms”。叶子节点“短报文丢包”(链路)对应于判定条件“链路环回短包丢包数》0”。叶子节点“短报文响应时间过长”(链路)对应于判定条件“链路短包环回响应时间》50ms”。叶子节点“长报文丢包”(链路)对应于判定条件“链路环回长包丢包数》0”。叶子节点“长报文响应时间过长”(链路)对应于判定条件“链路长包环回响应时间》50ms”。叶子节点“接收报文异常丢弃”对应于判定条件“接收缓冲丢包数/接收包数》0.1%”。叶子节点“接收溢出错误”对应于判定条件“接收缓冲溢出包数/接收包数》0.1%”。叶子节点“发送报文异常丢弃”对应于判定条件“发送缓冲丢包数/发送包数》0.1%”。叶子节点“发送溢出错误”对应于判定条件“发送缓冲溢出包数/发送包数》0.1%”。叶子节点“接收错误报文过多”对应于判定条件“接收损坏包数/接收包数》0.1%”。叶子节点“接收帧错误过多”对应于判定条件“接收帧错误数/接收包数》0.1%”。叶子节点“发送错误报文过多”对应于判定条件“发送损坏包数/发送包数》0.1%”。叶子节点“发送冲撞报文过多”对应于判定条件“发送冲撞数/发送包数》0.1%”。叶子节点“发送载波错误过多”对应于判定条件“发送载波错误数/发送包数》0.01%”。
66.通过详细定义有关环回异常故障的所有故障分类的判定条件,可以实现自动且精细的故障判定。此外,通过将多个故障节点进行分层,可以实现故障的逐层推导,由此可以提升故障推导的准确性,且降低了推导难度。
67.应理解,当计算单元150的故障判定模块220确定了待分析数据240中的至少部分数据满足故障判定条件250中的部分判定条件时,即可以从叶子节点274中确定相应的叶子节点,并且计算单元150的故障推导模块230可以基于上文详细描述的故障树270来确定上述叶子节点的上层关联节点,例如,父节点。
68.在某些实施例中,如图3所示,故障树270中的每个叶子节点仅对应于一个故障判定条件,并且两个或更多个下层节点的组合可以推导出上层关联节点。作为“或”关系的示例,如图3所示,叶子节点“接收错误报文过多”以及叶子节点“接收帧错误过多”均可以推导出“接收报文错误过多”的上层关联节点。
69.应理解,当基于叶子节点向上推导关联节点时,如果推导路径上均为“或”的关系,则可以基于一个或多个叶子节点直接推导至故障树270中的根节点。作为示例,计算单元
150可以根据诸如故障树270的因果关系信息确定叶子节点“接收错误报文过多”与叶子节点“接收帧错误过多”之间的逻辑关系。如果确定逻辑关系为或,则计算单元150可以基于叶子节点“接收错误报文过多”与叶子节点“接收帧错误过多”中的一个来确定关联节点。也就是说,当确定两个叶子节点之间存在或的逻辑关系时,由于确定了其中一个叶子节点的故障,故可以直接确定作为其上层节点的关联节点。
70.此外,虽然图3中未示出,也可以通过“与”的关系来推导上层关联节点。作为示例,需要叶子节点“每秒接收冲撞报文数达到预定阈值”以及叶子节点“网卡工作模式为半双工”均满足条件才可以推导出“网卡接收冲撞报文过多”的上层关联节点。应理解,当推导路径中存在“与”的关系时,向上推导关联节点的操作会在不满足相应推导关系时停止。备选地或附加地,无论是“或”的关系还是“与”的关系,可以限制向上推导的层级的数目阈值,例如,只推导最多三个层级的故障。作为示例,如果确定逻辑关系为与,计算单元150可以确定叶子节点“每秒接收冲撞报文数达到预定阈值”以及叶子节点“网卡工作模式为半双工”是否均满足条件,如果是,则可以基于两个叶子节点确定作为其上层节点的关联节点“网卡接收冲撞报文过多”。
71.通过限定“和”以及“与”的逻辑关系,可以提高上层关联节点的推导精度,丰富故障树的多样性,提升故障分析的准确性。
72.故障判定条件的优化
73.如前所述,故障判定条件250是用户基于经验或历史数据预先确定的。因此,仍然可能出现基于故障判定条件250中的个别判定条件确定出不准确的故障分析结果280的情况。为此,需要进行故障判定条件的优化。
74.在某些实施例中,可以通过预先训练的机器学习模型来基于故障分析结果280确定更新的故障判定条件250。具体地,故障判定条件250的更新优化可以分为两个阶段:机器学习模型的训练阶段和应用阶段。
75.在模型训练阶段中,可以利用基于历史数据标记的训练数据集来训练该机器学习模型。作为示例,当用户发现故障分析结果280不准确或不满意时,可以修改故障分析结果。由此,可以收集大量历史数据,并且可以将经修改的故障分析结果作为机器学习模型的输入、以及将相应的故障判定条件作为机器学习模型的输入,来对机器学习模型进行训练。
76.在模型应用阶段中,可以将被确定为不准确的故障分析结果280输入训练好的机器学习模型中,机器学习模型输出的结果即为更新后的故障判定条件250。以此方式,可以实现故障判定条件的自动优化,提高故障分析的准确性。
77.示例过程、装置和设备
78.图4示出了根据本公开的实施例的用于故障分析的过程400的流程图。在某些实施例中,方法400可以在图1和图2中的计算单元150以及图6示出的设备中实现。现参照图1和图2描述根据本公开实施例的用于故障分析的过程400。为了便于理解,在下文描述中提及的具体实例均是示例性的,并不用于限定本公开的保护范围。
79.在框402,可以由用户或计算单元150获取网卡设备140的待分析数据。此外,计算单元150还可以进一步获取用于分析网卡设备140的故障的因果关系信息,例如,故障树270。故障树270中的每个节点可以用于指示网卡设备140的一种故障。在某些实施例中,计算单元150可以通过数据采集模块210实时获取网卡设备140的操作数据。作为示例,网卡设
备140的操作数据可以包含网卡设备140的操作数据和/或日志数据。操作数据可以是网卡设备140的性能或其他工作参数,并且日志数据可以是网卡设备140在运行过程中产生的日志事件记录。备选地或附加地,计算单元150还可以获取由用户自行定义的附加模块,从而可以为计算单元150添加适用于不同应用场景的故障判定条件。作为示例,附加模块可以是环回异常检测模块。也就是说,当用户需要更新或者修改故障判定条件250时,其可以向计算单元150中的故障判定模块220挂载附加模块,以便更新故障判定条件250中的一个或多个判定条件。
80.在框404,计算单元150可以将待分析数据与故障树270所对应的多个故障判定条件250进行比对,以确定待分析数据中是否存在符合故障判定条件250的数据,如果确定待分析数据满足与故障树270的至少一个叶子节点相对应的故障判定条件,进入框406。作为示例,待分析数据可以是网卡设备140的网关环回短包丢包数。如果获取的网关环回短包丢包数大于0,则可以确定该待分析数据满足一个故障判定条件。由此,在框406,计算单元150可以从故障树270中确定与该故障判定条件相对应的叶子节点,并且基于故障树270确定该叶子节点的父节点,如果该父节点还存在上层级节点,则可以继续确定该叶子节点的父节点的父节点,直至推导出根节点或位于故障树的较高层级的节点,即,相关节点。
81.在框408,计算单元150可以进一步确定故障树270中的、叶子节点的关联节点。应理解,叶子节点和关联节点均是诸如故障树270的因果关系信息中的因果关系节点。进而,在框410,计算单元150可以至少基于该关联节点指示的故障(还可以基于叶子节点指示的故障),输出针对网卡设备140的故障分析结果280。作为示例,如图3所示,如果计算单元150基于故障判定条件确定了叶子节点“接收错误报文过多”以及“发送错误报文过多”,则计算单元150可以基于故障树270确定叶子节点“接收错误报文过多”的中层级节点“接收报文错误过多”以及叶子节点“发送错误报文过多”的中层级节点“发送报文错误过多”,进而可以基于中层级节点“接收报文错误过多”或者中层级节点“发送报文错误过多”进一步确定高层级节点“错误报文过多”,并且最终确定根层级节点“网卡传输故障”。由此,计算设备150可以通过诸如显示屏的输出单元向用户展示诸如“接收错误报文过多以及发送错误报文过多

接收报文错误过多以及发送报文错误过多

错误报文过多

网卡传输故障”的故障图或故障链,作为故障分析结果280。
82.通过以上方式,解决了人工运维的上述诸多问题,实现了网卡设备的故障分析自动化。通过对网卡设备140的各待分析数据与故障树270中的叶子节点的故障进行关联,可以基于待分析数据中的某一项或多项数据来判定相应的叶子节点处指示的故障是否发生。由此,可以自动快速地分析并确定出各个层级的故障模式,无需诸如运维人员的用户依靠经验进行故障推导,并且可以为用户后续的故障处理提供更为详细的参考信息。具体来说,一方面,上述实施例提出的故障检测过程可以有效遍历所有可能发生的故障,从而提升了故障检测过程的准确性和全面性。另一方面,当确定了与故障对应的叶子节点之后,上述实施例进一步基于故障树来推导上述叶子节点的上层关联节点,从而可以准确确定网卡设备发生故障的根因。因此,上述故障推导过程简化了诸如运维人员的用户的故障排查难度,减少了故障排查时间。
83.在某些实施例中,故障分析结果280可以按照简略模式来向用户展示。作为示例,可以仅呈现故障树270中满足故障条件的每一层节点。备选地或者附加地,还可以按照详细
模式来展示故障分析结果280。作为示例,不论是否检测出任何故障,均向用户呈现完整的故障树270,同时可以为被确定为故障的部分节点标注特殊符号或者颜色加以区分。以此方式,可以便于用户找到各故障间的关联关系,即“故障图”或者“故障链”。从而为后续的故障解决过程提供详细参考信息。
84.图5示出了根据本公开的一些实施例的用于故障分析的装置500的示意性框图。如图5所示,装置500可以包括获取模块502,期用于获取网卡设备140的待分析数据240和用于分析网卡设备140的故障的故障树270。在某些实施例中,故障树270中的每个节点指示网卡设备140的一个故障。装置500还可以包括叶子节点确定模块504。当确定待分析数据240满足故障判定条件250时,叶子节点确定模块504可以确定故障树270中的与故障判定条件250相对应的叶子节点。此外,装置500还可以包括关联节点确定模块506,其用于确定故障树270中的、叶子节点的关联节点。装置500可以进一步包括故障分析结果确定模块508。故障分析结果确定模块508可以基于关联节点指示的故障确定针对网卡设备140的故障分析结果280。
85.在一些实施例中,叶子节点可以包括第一叶子节点和第二叶子节点,并且关联节点确定模块506可以进一步被配置为:如果确定待分析数据240满足与第一叶子节点相对应的故障判定条件以及与第二叶子节点相对应的故障判定条件,确定关联节点。
86.在一些实施例中,关联节点可以包括故障树270中的根节点、叶子节点的父节点、叶子节点的父节点的父节点中的至少一个。
87.在一些实施例中,待分析数据240可以包括网卡设备140的操作数据和日志数据中的至少一种数据。
88.在一些实施例中,故障判定条件可以包括以下至少一项:网卡设备的网关环回短包丢包数大于第一阈值数目;网卡设备的网关短包环回响应时间大于第一阈值响应时间;网卡设备的网关环回长包丢包数大于第二阈值数目;网卡设备的网关长包环回响应时间大于第二阈值响应时间;网卡设备的链路环回短包丢包数大于第三阈值数目;网卡设备的链路短包环回响应时间大于第三阈值响应时间;网卡设备的链路环回长包丢包数大于第四阈值数目;以及网卡设备的链路长包环回响应时间大于第四阈值响应时间。
89.在一些实施例中,装置500还可以包括:分析结果比较模块,被配置为将故障分析结果与实际分析结果进行比较,实际分析结果是由用户确定的;以及更新模块,被配置为如果故障分析结果与实际分析结果不同,将实际分析结果应用于判定条件更新模型,以确定更新后的故障判定条件,其中判定条件更新模型是基于作为判定条件更新模型的输入的参考分析结果以及作为判定条件更新模型的输出的经标记的参考故障判定条件来训练得到的。
90.图6示出了可以用来实施本公开的实施例的示例设备600的示意性框图。如图6所示,设备600包括计算单元601,其可以根据存储在随机存取存储器(ram)603和/或只读存储器(rom)602的计算机程序指令或者从存储单元608加载到ram 603和/或rom 602中的计算机程序指令,来执行各种适当的动作和处理。在ram 603和/或rom 602中,还可存储设备600操作所需的各种程序和数据。计算单元601和ram 603和/或rom 602通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。
91.设备600中的多个部件连接至i/o接口605,包括:输入单元606,例如键盘、鼠标等;
输出单元607,例如各种类型的显示器、扬声器等;存储单元608,例如磁盘、光盘等;以及通信单元609,例如网卡、调制解调器、无线通信收发机等。通信单元609允许设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
92.计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理,例如过程400。例如,在一些实施例中,过程400可被实现为计算机软件程序,其被有形地包含于机器可读介质,例如存储单元608。在一些实施例中,计算机程序的部分或者全部可以经由ram 603和/或rom 602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到ram 603和/或rom 602并由计算单元601执行时,可以执行上文描述的过程400的一个或多个步骤。备选地,在其他实施例中,计算单元601可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行过程400。
93.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
94.在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
95.此外,虽然采用特定次序描绘了各操作,但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行,或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下,多任务和并行处理可能是有利的。同样地,虽然在上面论述中包含了若干具体实现细节,但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地,在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。
96.尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题,但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反,上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。
再多了解一些

本文用于创业者技术爱好者查询,仅供学习研究,如用于商业用途,请联系技术所有人。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献