故障根源确定方法及装置、电子设备和可读存储介质与流程

本公开涉及计算机技术领域，更具体地，涉及一种故障根源确定方法、一种故障根源确定装置、一种电子设备和一种计算机可读存储介质。

背景技术：

随着互联网的飞速发展，数据中心作为信息化社会的计算机基础设施，存储和管理大量关键数据，承载着各种数据的采集、存储及分析等功能，发挥着越来越重要的作用。

随着互联网金融的推广和普及，虚拟化和云平台等技术在数据中心的大范围使用，已经使运维人员需要运维的服务器和设备的台套数在近年内有数量级的增长。

如果数据中心一旦出现设备故障，工作人员就需要根据监控项的告警详情分析故障。在相关技术中，大多是依靠经验丰富的专业运维人员通过计算机来监管平台系统、网络、设备等的各项指标，已经无法满足当前运维体量的要求。

因此，如何适应当前运维体量的要求，以实现数据中心的智能化管理，越来越得到业内广泛重视。

技术实现要素：

有鉴于此，本公开提供了一种故障根源确定方法、一种故障根源确定装置、一种电子设备和一种计算机可读存储介质。

本公开的一个方面提供了一种故障根源确定方法，包括：获取被监控系统的多个告警事件，其中，上述多个告警事件中的每个告警事件具有对应的属性信息；根据上述每个告警事件对应的属性信息，对上述多个告警事件进行聚类分析，生成至少一个告警事件子集，其中，每个告警事件子集中包括多个告警事件；根据上述每个告警事件子集中的多个告警事件的属性信息，确定不同告警事件之间的因果关系；以及根据上述每个告警事件子集中不同告警事件之间的因果关系，从上述每个告警事件子集中的多个告警事件中确定发生故障的根源事件。

根据本公开的实施例，还包括：展示上述根源事件中描述的告警信息；以及生成用于解决上述故障的处理方案。

根据本公开的实施例，获取被监控系统的多个告警事件包括：从告警集中服务器中采集上述被监控系统的多个告警日志；对上述多个告警日志进行处理，生成具有预定格式的多个告警事件；以及确定上述每个告警事件的属性信息。

根据本公开的实施例，上述属性信息包括以下至少之一：上述被监控系统的配置属性信息、告警类别、发生告警的时间属性、故障标签。

根据本公开的实施例，根据上述每个告警事件对应的属性信息，对上述多个告警事件进行聚类分析，生成至少一个告警事件子集包括：实时获取最新产生的上述被监控系统的告警事件；以及对最新产生的告警事件和上述多个告警事件重新进行聚类分析，重新生成告警事件子集，以便对已经生成的告警事件子集进行更新。

本公开的另一个方面提供了一种故障根源确定装置，包括：获取模块，用于获取被监控系统的多个告警事件，其中，上述多个告警事件中的每个告警事件具有对应的属性信息；聚类模块，用于根据上述每个告警事件对应的属性信息，对上述多个告警事件进行聚类分析，生成至少一个告警事件子集，其中，每个告警事件子集中包括多个告警事件；第一确定模块，用于根据上述每个告警事件子集中的多个告警事件的属性信息，确定不同告警事件之间的因果关系；第二确定模块，用于根据上述每个告警事件子集中不同告警事件之间的因果关系，从上述每个告警事件子集中的多个告警事件中确定发生故障的根源事件。

根据本公开的实施例，故障根源确定装置还包括展示模块，用于展示上述根源事件中描述的告警信息；生成模块，用于生成用于解决上述故障的处理方案。

根据本公开的实施例，获取模块包括：采集单元，用于从告警集中服务器中采集上述被监控系统的多个告警日志；处理单元，用于对上述多个告警日志进行处理，生成具有预定格式的多个告警事件；以及确定单元，用于确定上述每个告警事件的属性信息。

根据本公开的实施例，上述聚类模块包括：获取单元，用于实时获取最新产生的上述被监控系统的告警事件；以及分析单元，用于对最新产生的告警事件和上述多个告警事件重新进行聚类分析，重新生成告警事件子集，以便对已经生成的告警事件子集进行更新。

本公开的另一方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个指令，其中，当上述一个或多个指令被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，因为采用了对多个告警事件进行聚类分析，根据多个告警事件的属性信息确定不同告警事件之间的因果关系，从而确定发生故障的根源事件的技术手段，所以至少部分地克服了如何适应当前运维体量的要求，以实现数据中心的智能化管理的技术问题，进而达到了保障运维人员能够快速从海量报警中提取重要事件告警，快速定位故障点，初步圈定根源事件，提高监控智能化，提升告警准确率和故障处理时效，避免生产故障事件影响的快速蔓延的技术效果。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的可以应用故障根源确定方法及装置的示例性系统架构；

图2示意性示出了根据本公开实施例的故障根源确定方法的流程图；

图3示意性示出了根据本公开实施例的获取被监控系统的多个告警事件的流程图；

图4示意性示出了根据本公开实施例的生成至少一个告警事件子集的流程图；

图5示意性示出了根据本公开实施例的故障根源确定装置的框图；以及

图6示意性示出了根据本公开实施例的适于实现上文描述的故障根源确定方法的电子设备的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。

在日常监控运维过程中，被监控系统的服务器的数量大量增加，一线监控值班人员经常遇到生产故障事件告警频出，甚至是告警风暴的情况，无法快速确定故障影响范围。二线运维人员也无法根据报警内容快速定位根源故障事件和原因。数据中心监控告警类别丰富，故障所属专业可分为主机专业、应用专业、开放系统(操作系统、数据库、中间件、存储、其他)专业、网络专业、设备专业等等。根据告警形式可分为状态类告警、阈值类告警、日志类告警。生产故障事件发生时，上述告警分类的故障事件可能会同时发生，以至于很难简单的通过告警事件定位根源事件的所属专业、告警内容，甚至是应用维护人员更关心的故障应用。

为了适应数据中心长期稳定运营的实际需要，实现数据中心智能化管理已是大势所趋。若能结合深度学习、人工智能技术对数据中心进行智能化管理，将可有效提高数据中心的智能化运维水平，而其中涉及的数据中心智能监控及故障处理也是其中重要的研究课题，本公开针对数据中心监控告警的智能优化，可以提高运维人员的故障定位和应急处理能力。

本公开的实施例提供了一种故障根源确定方法，包括：获取被监控系统的多个告警事件，其中，多个告警事件中的每个告警事件具有对应的属性信息；根据每个告警事件对应的属性信息，对多个告警事件进行聚类分析，生成至少一个告警事件子集，其中，每个告警事件子集中包括多个告警事件；根据每个告警事件子集中的多个告警事件的属性信息，确定不同告警事件之间的因果关系；以及根据每个告警事件子集中不同告警事件之间的因果关系，从每个告警事件子集中的多个告警事件中确定发生故障的根源事件。

图1示意性示出了根据本公开实施例的可以应用故障根源确定方法及装置的示例性系统架构。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备110，被监控系统120和网络130。网络130用以在终端设备110和被监控系统120之间提供通信链路的介质。网络130可以包括各种连接类型，例如有线和/或无线通信链路等等。被监控系统120包括被监控设备121、被监控设备122和被监控设备123。

用户可以使用终端设备110通过网络130与被监控系统120交互，以接收或发送消息等。终端设备110可以是具有具有计算能力的各种电子设备，包括但不限于服务器、智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

被监控系统120可以包括提供各种服务的服务器。

本公开实施例所提供的故障根源确定方法也可以由终端设备110执行，或者也可以由不同于终端设备110的其他终端设备执行。相应地，本公开实施例所提供的故障根源确定装置也可以设置于终端设备110中，或设置于不同于终端设备110的其他终端设备中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图2示意性示出了根据本公开实施例的故障根源确定方法的流程图。

如图2所示，该方法包括操作s210～s240。

在操作s210，获取被监控系统的多个告警事件，其中，多个告警事件中的每个告警事件具有对应的属性信息。

根据本公开的实施例，属性信息可以包括以下至少之一：被监控系统的配置属性信息、告警类别、发生告警的时间属性、故障标签。

根据本公开的实施例，可以利用关联聚类方法，将告警事件集合划分为具有故障关联属性的子集。

在操作s220，根据每个告警事件对应的属性信息，对多个告警事件进行聚类分析，生成至少一个告警事件子集，其中，每个告警事件子集中包括多个告警事件。

根据本公开的实施例，在告警事件子集中，可以以图形结构模拟各事件的发生时序及关联属性，挖掘其根源节点及条件概率，生成故障的排查流程和指导方案。

在操作s230，根据每个告警事件子集中的多个告警事件的属性信息，确定不同告警事件之间的因果关系。

根据本公开的实施例，在告警事件子集中，利用前序事件关联属性，生成告警事件关系图，并实现告警根源事件及条件概率的挖掘，通过分析多事件的因果关系，挖掘其根源节点，即故障根源事件，告警子集即为故障影响范围。

在操作s240，根据每个告警事件子集中不同告警事件之间的因果关系，从每个告警事件子集中的多个告警事件中确定发生故障的根源事件。

根据本公开的实施例，将告警事件的发生、关联、根源事件的形成及对应的生产故障的解决方案，通过页面交互展示给运维人员。

根据本公开的实施例，可以展示根源事件中描述的告警信息，生成用于解决故障的处理方案。

例如，通过页面展示装置根据前序根源分析结果和知识库，自动生成变更方案、应急处置方案和相应的页面展示数据，利用前端页面展示数据，呈现给运维人员。页面展示装置可以提供人工交互接口，对已生成的方案完成变更方案、应急处置方案的自动编写。将告警、故障、影响范围通过页面展示装置提供给运维人员，可以提高数据中心生产故障事件快速响应的能力。

在相关技术中，传统监控系统只具备告警展示的功能，用户需要根据告警信息查询相关配置、应用维护人、故障对象当前状态等内容，占用大量的应急响应时间。本公开可以使用户更直观的定位故障及其影响范围，摒弃以外以节点为单位的监控模式。

根据本公开的实施例，数据中心等环境的生产管理人员，可以快速的定位生产故障事件的根源及其影响范围，快速有效的做出响应决策和应急部署安排，最大程度的规避生产故障事件的影响，防止故障的影响进一步扩散，满足数据中心快速响应需求。

根据本公开的实施例，数据中心等环节的生产运维人员，在监控系统智能化提升方面推进了一大步，数据挖掘和智能创新提供新的生产力，解放了原有的一部分运维生产力，可以用于智能化技术的再提高，走向良性循环。

根据本公开的实施例，因为采用了对多个告警事件进行聚类分析，根据多个告警事件的属性信息确定不同告警事件之间的因果关系，从而确定发生故障的根源事件的技术手段，所以至少部分地克服了如何适应当前运维体量的要求，以实现数据中心的智能化管理的技术问题，进而达到了保障运维人员能够快速从海量报警中提取重要事件告警，快速定位故障点，初步圈定根源事件，提高监控智能化，提升告警准确率和故障处理时效，避免生产故障事件影响的快速蔓延的技术效果。

下面参考图3～图4，结合具体实施例对图2所示的方法做进一步说明。

图3示意性示出了根据本公开实施例的获取被监控系统的多个告警事件的流程图。

如图3所示，该获取被监控系统的多个告警事件包括操作s310～s330。

在操作s310，从告警集中服务器中采集被监控系统的多个告警日志。

根据本公开的实施例，可以通过部署在告警集中服务器上的日志采集程序，实时采集被监控系统的告警事件。将收集到的告警消息通过告警格式匹配生成告警事件。

例如，通过在被监控系统和告警集中服务器上部署syslog服务及配置，完成数据中心告警日志集中，在监控日志集中服务器上部署开源日志采集工具，用于日志文件的动态日志抓取，传输至告警规则匹配程序中，完成日志清洗和告警事件生成及分类的流程。

在操作s320，对多个告警日志进行处理，生成具有预定格式的多个告警事件。

根据本公开的实施例，可以在数据中心部署告警集中架构体系，收集来自各被监控系统产生的指标类和日志类告警日志消息，将被监控系统告警日志通过告警模式匹配，生成告警事件，对告警数据进行清洗和整理分类，将日志消息形成分析系统可用的状态类告警事件、阈值类告警事件、日志类告警事件等等。

在操作s330，确定每个告警事件的属性信息。

根据本公开的实施例，可以通过集中告警日志，以优化告警效率，实现监控告警的统一数据管理。例如，生产服务器操作系统基线要求开启rsyslog服务，在所有被监控系统上配置如下内容(xxx代表监控日志集中服务器ip地址)：

auth.notice@xxx.xxx.xxx.xxx：514；

user.notice@xxx.xxx.xxx.xxx：514。

在告警集中服务器做如下配置，收集所有被监控系统上传的监控日志。sourceoscmsrc{udp(ip(0.0.0.0)port(514))；}。

根据本公开的实施例，可以利用开源日志采集软件动态实时采集报警日志集中文件，关键参数配置如下：

paths：-/var/log/ncolog.log；

encoding：gbk；

include_lines：[′user.notice′]。

根据本公开的实施例，在告警日志动态采集的环节完成后，可以根据告警事件来源、告警事件类别、报警公式匹配结果清洗掉不规范的报警日志，存留在系统报错日志文件中。正常匹配的告警日志生成告警事件。

图4示意性示出了根据本公开实施例的生成至少一个告警事件子集的流程图。

如图4所示，根据每个告警事件对应的属性信息，对多个告警事件进行聚类分析，生成至少一个告警事件子集包括操作s410～s420。

在操作s410，实时获取最新产生的被监控系统的告警事件。

在操作s420，对最新产生的告警事件和多个告警事件重新进行聚类分析，重新生成告警事件子集，以便对已经生成的告警事件子集进行更新。

根据本公开的实施例，可以实时获取最新产生的被监控系统的告警事件，即实现动态收集告警事件，形成动态的告警事件池，在配置属性、告警类别、时间属性、故障标签的过程中，聚类生成动态告警事件子集合，告警事件子集合内的告警事件体现了当前状态下基于故障的强关联性。

根据本公开的实施例，可以基于图分析和条件概率，完成告警事件的关键路径搜索，计算出根源事件及概率，挖掘出告警事件发生的因果联系。

图5示意性示出了根据本公开实施例的故障根源确定装置的框图。

如图5所示，故障根源确定装置500包括获取模块510、聚类模块520、第一确定模块530和第二确定模块540。

获取模块510用于获取被监控系统的多个告警事件，其中，多个告警事件中的每个告警事件具有对应的属性信息。

聚类模块520用于根据每个告警事件对应的属性信息，对多个告警事件进行聚类分析，生成至少一个告警事件子集，其中，每个告警事件子集中包括多个告警事件。

第一确定模块530用于根据每个告警事件子集中的多个告警事件的属性信息，确定不同告警事件之间的因果关系。

第二确定模块540用于根据每个告警事件子集中不同告警事件之间的因果关系，从每个告警事件子集中的多个告警事件中确定发生故障的根源事件。

根据本公开的实施例，因为采用了对多个告警事件进行聚类分析，根据多个告警事件的属性信息确定不同告警事件之间的因果关系，从而确定发生故障的根源事件的技术手段，所以至少部分地克服了如何适应当前运维体量的要求，以实现数据中心的智能化管理的技术问题，进而达到了保障运维人员能够快速从海量报警中提取重要事件告警，快速定位故障点，初步圈定根源事件，提高监控智能化，提升告警准确率和故障处理时效，避免生产故障事件影响的快速蔓延的技术效果。

根据本公开的实施例，例如，第一确定模块530和第二确定模块540可以组成根源分析装置。根源分析装置可以基于马尔科夫链解决时序根源事件判断问题，利用马尔科夫的概率转移链，从一系列告警事件中推断出哪一个是根源事件。

基于马尔科夫的因果知识挖掘方法，为因果知识的挖掘提供了一种新的方向，针对边界数据状态难以确定的问题，将信度理论引入马尔科夫，形成信度马尔科夫模型。

同时，引入时变的想法，时变加权马尔科夫模型考虑了不同时间段的状态间客观存在的相依关系，可以提高检测精度，模型复杂度可控。

马尔科夫模型认为几个单点时刻的状态能够在一定程度上确定未来某一时刻的状态，充分发挥历史数据的作用，使检测结果具有一定的可信度。

马尔科夫过程是一个典型的随机过程，当过程在t0时刻所处的状态已知时，t0之后的时刻所处的状态与过程在t0时刻之前的状态无关，上述特性称为无后效性。马尔科夫模型具体公式描述如下：

p{xn+1＝in+1|x0＝i0，...，xn＝in}＝p{xn+1＝in+1|xn＝in}(一)

马尔科夫过程中的时间和状态可以是离散的，也可以是连续的。时间离散、状态离散的马尔科夫过程被称为马尔科夫链。马尔科夫链中各个时刻的状态的转变由状态转移概率矩阵控制，传统的马尔科夫链模型往往假设系统状态转移概率矩阵是不随时间变化的，然而在许多实际问题中，状态的转移概率矩阵是随时间不断变化的，符合该特性的马尔科夫链模型是时变马尔科夫链模型。

本公开采用一种基于组合状态的时变加权马尔科夫链数据中心故障告警检测模型，使用数据中心在实际运维中产生的告警数据作为实验数据集，能够自动地根据现有的历史告警事件推断出根源事件，同时给出对应的置信度，保证了数据中心设备运行的稳定性、安全性和各种业务的正常运行。

由于数据中心故障场景复杂，这造成了生成的报警事件子集体现的生产故障影响范围存在维度差异，维度包括：单台服务器或设备故障(a类故障状态)、应用维度的多台服务器故障(b类故障状态)、网络区域涉及到服务器或者设备故障(c类故障状态)等。在本公开的实施例中，单台服务器或设备故障可抽象为一阶马尔科夫过程，在此基础上提出了一种自适应马尔科夫过程。根据告警事件子集的生产故障事件影响范围判定，生成对应维度的马尔科夫链，维度代表相应的监控指标类型和个数。

本公开提供了一种自适应马尔科夫过程，可根据告警事件子集维度，求解其对应阶马尔科夫过程，进而推断告警事件子集中的根源事件。

根据本公开的实施例，基于马尔科夫链模型的根源事件判定步骤如下：

1、根据告警事件子集内容生成马尔科夫链模型初始状态矩阵s。

初始状态矩阵的行代表报警对象，初始状态矩阵的列代表自适应后的告警指标。例如：

2、对n(j、k、l)维告警事件子集，利用极大似然估计的方式，依据时序获取告警事件子集各维度由事件i转移到事件g的条件概率p(m)＝pi，gⁿ(m)＝p{s(i)|s(g)}(n＝j、k、l)，该概率根据历史报警统计得出。

其中，j代表服务器或设备的监控指标，k代表服务器或设备、应用状态、可用性、交易率的监控指标，l代表服务器或设备、应用状态、可用性、交易率、网络链路、端口、交换机、存储设备等监控指标等。

3、转移概率矩阵为告警子集中告警事件条件概率的集合。转移概率矩阵行为告警子集单条事件与其他事件的条件概率，列为逐条事件。

下面以数据中心中设备的不同报警案例进行说明。

例如，案例1：单台服务器发生虚拟内存使用率高、内存使用率高、服务中间件状态异常。

通过分析告警事件的配置属性、告警类别、时间属性、故障标签，动态生成告警事件集合，即生成生产故障事件影响范围内的告警事件子集。

若告警事件子集只包含单台服务器的多个告警事件，则根据算法自适应为如下马尔科夫过程。

得到初始状态矩阵和转移概率矩阵，计算出告警1为根源事件的概率为55％，告警2为根源事件的概率为30％，两类事件为根源事件的概率大于85％，则停止根源事件概率计算。

案例2：多台服务器发生连接数高、网页服务状态异常、应用交易率下降、服务中间件状态异常、数据库数据库集群实例宕。

案例3：多台服务器连通性不通、多应用交易率下降、某区域单台交换机连通性异常。

生成了对应告警事件子集的根源事件及其概率结果，以告警事件子集涉及的告警对象为生产故障影响范围。在页面展示装置中展示告警子集列表及对应的根源告警事件排序，排序顺序以上述过程求出的条件概率由高到低生成，同时在知识库中调取对应根源事件的解决方案，提供给用户。

在页面展示时，可以根据前序步骤提供的根源事件及其置信度，利用知识库中存储的历史变更及应急处置实施过程，自动化生产新的方案数据，用于展示给用户。

根据本公开的实施例，故障根源确定装置500还包括展示模块和生成模块。

根据本公开的实施例，展示模块用于展示根源事件中描述的告警信息。

根据本公开的实施例，生成模块用于生成用于解决故障的处理方案。

根据本公开的实施例，获取模块510包括采集单元、处理单元和确定单元。

根据本公开的实施例，采集单元用于从告警集中服务器中采集被监控系统的多个告警日志。

根据本公开的实施例，处理单元用于对多个告警日志进行处理，生成具有预定格式的多个告警事件。

根据本公开的实施例，确定单元用于确定每个告警事件的属性信息。

根据本公开的实施例，聚类模块520包括获取单元和分析单元。

根据本公开的实施例，获取单元用于实时获取最新产生的被监控系统的告警事件。

根据本公开的实施例，分析单元用于对最新产生的告警事件和多个告警事件重新进行聚类分析，重新生成告警事件子集，以便对已经生成的告警事件子集进行更新。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，获取模块510、聚类模块520、第一确定模块530和第二确定模块540中的任意多个可以合并在一个模块/单元/子单元中实现，或者其中的任意一个模块/单元/子单元可以被拆分成多个模块/单元/子单元。或者，这些模块/单元/子单元中的一个或多个模块/单元/子单元的至少部分功能可以与其他模块/单元/子单元的至少部分功能相结合，并在一个模块/单元/子单元中实现。根据本公开的实施例，获取模块510、聚类模块520、第一确定模块530和第二确定模块540中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，获取模块510、聚类模块520、第一确定模块530和第二确定模块540中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

需要说明的是，本公开的实施例中故障根源确定装置部分与本公开的实施例中故障根源确定方法部分是相对应的，故障根源确定装置部分的描述具体参考故障根源确定方法部分，在此不再赘述。

本公开还提供了一种电子设备包括：一个或多个处理器；存储器，用于存储一个或多个指令，其中，当所述一个或多个指令被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的方法。

图6示意性示出了根据本公开实施例的适于实现上文描述的故障根源确定方法的电子设备的框图。图6示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图6所示，根据本公开实施例的电子设备600包括处理器601，其可以根据存储在只读存储器(rom)602中的程序或者从存储部分608加载到随机访问存储器(ram)603中的程序而执行各种适当的动作和处理。处理器601例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器601还可以包括用于缓存用途的板载存储器。处理器601可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在ram603中，存储有电子设备600操作所需的各种程序和数据。处理器601、rom602以及ram603通过总线604彼此相连。处理器601通过执行rom602和/或ram603中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom602和ram603以外的一个或多个存储器中。处理器601也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备600还可以包括输入/输出(i/o)接口605，输入/输出(i/o)接口605也连接至总线604。电子设备600还可以包括连接至i/o接口605的以下部件中的一项或多项：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至i/o接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被处理器601执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可渎存储介质可以是非易失性的计算机可渎存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom602和/或ram603和/或rom602和ram603以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。