CN116032782A - 故障检测方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种故障检测方法、设备及存储介质，该方法包括获取多个网络设备的运行信息，并对多个网络设备的运行信息进行整合，获得多个网络设备的运维信息，从运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息，关联设备为与待检测设备具有关联关系的设备，将第一运维信息和第二运维信息输入故障预测模型，获得待检测设备的故障提示信息。本申请实施例提供的故障检测方法，能够提高网络设备的故障检测的效率和准确率。

Description

故障检测方法、设备及存储介质

技术领域

本申请实施例涉及大数据处理技术领域，尤其涉及一种故障检测方法、设备及存储介质。

背景技术

随着近年来云计算、大数据等技术的迅猛发展，数据中心的规模正在快速增长，网络环境变得越来越复杂，对于问题响应时间、可用性、可靠性等各项指标的要求也越来越严格。

相关技术中，通常是根据网络设备的告警信息通过人工进行故障判断。

然而，实现本申请过程中，发明人发现现有技术中至少存在如下问题：数据中心具设备品牌型号多样、业务规模大，上述方式需要依靠一线运维值班人员24*7随时应急以完成设备硬件故障的发现和处理，浪费人力，且效率较差且准确率低。

发明内容

本申请实施例提供一种故障检测方法、设备及存储介质，以提高故障检测的效率和准确率。

第一方面，本申请实施例提供一种故障检测方法，包括：

获取多个网络设备的运行信息，并对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息；

从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备；

将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

在一种可能的设计中，所述获取多个网络设备的运行信息，包括：

获取多个网络设备的元数据；

针对多个所述网络设备中的每个网络设备，若所述网络设备的元数据表明所述网络设备存在采集接口，则通过所述采集接口采集所述网络设备的运行信息；

若所述网络设备的元数据表明所述网络设备不存在采集接口，则基于简单网络管理协议SNMP采集所述网络设备的运行信息；

若基于SNMP采集失败，则根据所述元数据中的设备配置命令，下发命令并获取回显，获得所述网络设备的运行信息。

在一种可能的设计中，所述对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息，包括：

对多个所述网络设备的运行信息进行清洗，获得清洗后的运行信息；

根据多个所述网络设备之间的关联关系，对所述清洗后的运行信息进行整合，获得所述多个网络设备的运维信息。

在一种可能的设计中，所述对多个所述网络设备的运行信息进行清洗，获得清洗后的运行信息，包括：

确定所述运行信息中的残缺数据和重复数据，并对所述残缺数据进行补全，将所述重复数据删除，获得清洗后的运行信息。

在一种可能的设计中，所述将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息，包括：

基于结构分析算法，构建待检测设备的关联图；

根据所述关联图构建待训练图卷积神经网络；

获取待检测设备的历史运维数据和关联设备的历史运维数据，并根据所述历史运维数据确定样本集；

根据所述样本集对所述待训练图卷积神经网络进行训练，获得故障预测模型；

将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

在一种可能的设计中，所述运行信息包括多个所述网络设备的配置信息；所述方法还包括：

根据所述配置信息对多个所述网络设备进行基线核查。

在一种可能的设计中，所述根据所述运维信息对多个所述网络设备进行基线核查，包括：

根据多个所述网络设备的配置关联关系，确定待核查设备的配置区域的关联区域；

根据预设的基线核查规则，对所述配置区域和所述关联区域的配置信息进行基线核查，获得检查结果。

第二方面，本申请实施例提供一种故障检测设备，包括：

分帧模块，用于对待检测语音进行分帧处理，得到多个待检测的音帧；

检测模块，用于获取各所述待检测音帧的声学特征，并将各所述待检测音帧的声学特征依次输入至语音活动性检测VAD模型；其中，所述VAD模型用于将所述待检测语音中的前N个语音帧分类为噪声帧、将第N+1个语音帧至最后一个语音帧分类为语音帧以及将所述最后一个语音帧之后的M个噪声帧分类为语音帧，所述N和M为整数；

确定模块，用于根据所述VAD模型输出的分类结果确定语音段的起点和终点；其中，所述起点对应首个被分类为语音帧的音帧，所述终点对应最后一个被分类为语音帧的音帧。

第三方面，本申请实施例提供一种故障检测设备，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一方面以及第一方面各种可能的设计所述的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上第一方面以及第一方面各种可能的设计所述的方法。

本实施例提供的故障检测方法、设备及存储介质，该方法包括获取多个网络设备的运行信息，并对多个网络设备的运行信息进行整合，获得多个网络设备的运维信息，从运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息，关联设备为与待检测设备具有关联关系的设备，将第一运维信息和第二运维信息输入故障预测模型，获得待检测设备的故障提示信息。本申请实施例提供的故障检测方法，通过将数据中心的多个网络设备中获取其运行信息，并对运行信息进行整合后，获得运维信息，进而可以提取待检测设备和其关联设备的运维信息，并将该运维信息作为故障预测模型的输入，以通过故障预测模型进行预测，获得待检测设备的故障提示信息，不仅通过故障预测模型的应用实现了自动化，还通过结合待检测设备的关联设备的运行情况对待检测设备的故障进行预测提高了故障检测的准确率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的故障检测方法的应用场景示意图；

图2为本申请实施例提供的故障检测方法的流程示意图一；

图3为本申请实施例提供的信息处理平台的结构示意图；

图4为本申请实施例提供的故障预测模型的训练过程和应用过程的示意图；

图5为本申请实施例提供的故障检测方法的流程示意图二；

图6为本申请实施例提供的故障检测设备的结构示意图；

图7为本申请实施例提供的故障检测设备的硬件结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

随着近年来云计算、大数据等技术的迅猛发展，数据中心的规模正在快速增长，各类系统也变得越来越复杂，用户流量不断增加，相关的事件和变更需求也越来越多，网络环境变得越来越复杂，网络服务的负载也在爆炸式的增长，对于问题响应时间、可用性、可靠性等各项指标的要求也越来越严格。数据中心具有功能区域多、防护级别多、业务规模大、设备品牌型号多样、运维操作频繁等特点，意味着运维操作的复杂度在增加，运维难度升级。数据中心中存在着大量不同时期采购的网络设备，随着时间的推移，设备的硬件在逐渐的老化和损坏，可靠性也在逐渐的降低，由于器件在不同的环境、不同的使用条件下其失效率会有很大的区别，单个网络设备故障的出现是不可避免的且难以预测的。相关技术中是根据网络设备的告警信息通过人工进行故障判断，需要依靠一线运维值班人员24*7随时应急以完成设备硬件故障的发现和处理，浪费人力，且效率较差且准确率低。

为了解决上述技术问题，本申请发明人研究发现可以将数据中心的多个网络设备中获取其运行信息，并对运行信息进行整合后，获得运维信息，进而可以提取待检测设备和其关联设备的运维信息，并将该运维信息作为故障预测模型的输入，以通过故障预测模型进行预测，获得待检测设备的故障提示信息，不仅通过故障预测模型的应用实现了自动化，还通过结合待检测设备的关联设备的运行情况对待检测设备的故障进行预测提高了故障检测的准确率。基于此，本申请实施例提供一种故障检测方法，以提高网络设备故障检测的效率和准确率。

图1为本申请实施例提供的故障检测方法的应用场景示意图。如图1所示，故障检测设备101与数据中心的多个网络设备102通信连接。多个网络设备102中各网络设备根据实际需要进行互联。互联方式可以根据需求的更新而改变。故障检测设备101用于获取网络设备102的运行信息，并对多个所述网络设备102的运行信息进行整合，获得所述多个网络设备102的运维信息；从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备；将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。故障检测设备101可以是终端设备或服务器。本实施例对此不做限定。

在具体实现过程中，故障检测设备101获取多个网络设备102的运行信息，并对多个所述网络设备102的运行信息进行整合，获得所述多个网络设备102的运维信息；从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备；将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。本实施例提供的故障检测方法，通过将数据中心的多个网络设备中获取其运行信息，并对运行信息进行整合后，获得运维信息，进而可以提取待检测设备和其关联设备的运维信息，并将该运维信息作为故障预测模型的输入，以通过故障预测模型进行预测，获得待检测设备的故障提示信息，不仅通过故障预测模型的应用实现了自动化，还通过结合待检测设备的关联设备的运行情况对待检测设备的故障进行预测提高了故障检测的准确率。

需要说明的是，图1所示的场景示意图仅仅是一个示例，本申请实施例描述的故障检测以及场景是为了更加清楚地说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图2为本申请实施例提供的故障检测方法的流程示意图一。如图2所示，该方法包括：

201、获取多个网络设备的运行信息，并对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息。

本实施例的执行主体可以是终端设备或服务器。例如，如图1所示的故障检测设备101。

考虑到设备上的各类信息存在于各个设备、各个平台，缺乏统一查询、处理的方式。而且各种不同品牌网络设备的配置方式、方法不尽相同，需要一定的专业知识和品牌配置经验，较为繁琐且重复性较高。不同品牌拥有不同维护方式，操作逻辑也不统一，其信息的结构、表现形式、表现方法也不尽相同。且存在信息收集困难，一致性难以保障的问题。由于数据中心的网络规模较大、涉及的网络设备种类较多，且同类型设备中可能包含多个设备厂商、品牌、型号，且网络设备信息会产生多类信息，所产生的信息一般具有非结构化、专业性强、数据量大、更新频繁等特点，收集和管理难度不小。为了实现数据中心网络设备信息的智能处理和智能运维，提升网络服务可用性和可靠性，可以对各种网络设备的信息进行统一管理，以提升运维效率。

在一些实施例中，所述获取多个网络设备的运行信息，可以包括：获取多个网络设备的元数据；针对多个所述网络设备中的每个网络设备，若所述网络设备的元数据表明所述网络设备存在采集接口，则通过所述采集接口采集所述网络设备的运行信息；若所述网络设备的元数据表明所述网络设备不存在采集接口，则基于简单网络管理协议SNMP采集所述网络设备的运行信息；若基于SNMP采集失败，则根据所述元数据中的设备配置命令，下发命令并获取回显，获得所述网络设备的运行信息。

具体的，基于本申请实施例提供的故障检测方法，可以以信息处理平台的形式(示例性的，该平台可以基于NORNIR开源库进行开发)，有效的收集不同类型品牌的网络设备所产生的各类信息，并根据需要清洗、提取和聚合原始信息，提供更有效的运维数据。示例性的，如图3所示，该平台可以包括信息获取模块，通过信息获取模块对各网络设备进行信息的统一获取。

信息获取模块可以通过设备登陆功能、命令下发和回显获取功能、SNMP信息获取功能、SDN接口获取功能统一获取各类网络设备信息，包括各类网络设备(路由器、交换机、防火墙等)的软硬件信息、状态信息(版本、型号、端口、板卡等信息)、运行信息(配置、地址解析协议(Address Resolution Protocol，ARP)、介质访问控制(Media Access Control，MAC)地址、网段)、异常信息等自身信息或运行产生的信息。

由于网络架构在不断的演进，会出现多种形态并存的时期和情况。在这种情况下，设备所产生的信息无法通过统一的方式获取。因此，本实施例采用一种统一提取网络设备信息的方式，获取不同网络环境、不同品牌、不同型号的设备信息。

在整理全网设备或网络设备首次上线时，单体获取每台设备的具体信息和配置对于一线运维人员和设备管理员来说工作量非常大，因此，可以首先通过SNMP方式自动获取设备的基本信息，即元数据(设备的名称、品牌、型号、对象标识符(Object Identifier，OID)等)是首要的步骤。在获取设备基本信息之后，下一步可以根据基本信息，确定网络结构的差异，进而基于网络结构的差异对设备的运行信息(还可以包括告警信息、配置信息等)进行获取。具体的，在软件定义网络(Software Defined Network，SDN)等新型网络结构下，可以通过接口的方式采集运行信息，以提高效率和准确性。而在传统网络中，网络设备通常不能够通过接口的方式进行采集，因此可以通过下发命令获取回显或SNMP采集的方式收集设备运行信息和告警信息。例如可以选择通过show arp和dis arp等不同命令对不同种类的交换机设备的ARP信息进行收集，或者通过特定管理信息基础(ManagementInformation Base，MIB)号对网络设备的ARP、MAC信息进行收集并存储到对应的管理信息库中。考虑到通过SNMP方式进行信息获取是会更快速和准确，因此在一种可能的设计中，可以对于传统网络可以优先使用SNMP方式。具体可以根据实际需要进行设定，本实施例对此不做限定。

示例性的，信息获取模块进行信息采集的具体流程可以包括以下步骤：

首先，获取各网络设备基本信息并关联元数据库：通过SNMP方式采集设备的名称、品牌、型号、OID等基本信息，基于该基本信息对各网络设备进行初步的分类，不同类的网络设备具有不同的网络架构，例如第一类可以是SDC架构，第二类可以是传统网络架构。根据基本信息可以对不同设备的接口信息、采集命令、mib值对设备信息进行补充和完善。

其次，通过接口采集数据：对于在SDN架构下的网络设备，可以通过接口的方式获取网络设备的各类运行信息和告警信息。

再次，通过SNMP采集数据：对于不具备接口的传统网络架构下的网络设备，可以根据元数据库中的信息对网络设备进行分类，进而可以根据元数据库中获取的MIB信息，通过SNMPWALK和SNMPGET的方式进行采集。

对于无法通过SNMP方式或者采集失败的设备，通过元数据库中获取的设备配置命令，下发命令并获取回显。由于采集回来的设备回显是无格式的文本内容，该方式获取的信息需要通过数据处理模块进行初步的处理工作，将有用的信息从无序的文本中抽取出来，并转化为格式化信息。可以将上述三种方式(接口、SNMP、下发命令获取回显)所获取到的运行信息存储至基础信息库(详见后续实施例，此处不做赘述)。

如图3所示，信息处理平台还可以包括信息存储模块。信息存储模块可以包含元数据库、基础信息库、管理信息库和故障事件库。

其中，元数据库用于存储各网络设备的基本信息，例如OID对应的厂商、品牌、类型、规格等信息、设备所对应的各类采集或者配置命令等设备对应信息。

基础信息库用于存储各网络设备的运行信息和告警信息。即未经进一步加工、处理和分析的数据。

管理信息库用于存放设备相关的进阶信息，即运维人员在运维时关注的信息点。示例性的，可以用于存储处理后的运行信息和告警信息(可以是通过信息处理模块(详见后续实施例，此处不做赘述)对基础信息库中的运行信息进行清洗整合后得到的运维信息)。该库的设置，主要是考虑到网络设备会产生大量的日志，其中大部分日志对于运维工作并无意义，为了节省运维人员的查询工作量，可以将有用信息放置在管理信息库，以使运维人员快速调阅，并且可以将该库的数据作为故障预测模型的输入，以进行故障预测，获得故障提示信息。

故障事件库用于存储所有出现问题的相关事件、告警和设备运行信息，还包含了监控系统的以下四个指标，延迟，流量，错误和饱和度。

在一些实施例中，所述对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息，可以包括：对多个所述网络设备的运行信息进行清洗，获得清洗后的运行信息；根据多个所述网络设备之间的关联关系，对所述清洗后的运行信息进行整合，获得所述多个网络设备的运维信息。

在一些实施例中，所述对多个所述网络设备的运行信息进行清洗，获得清洗后的运行信息，可以包括：确定所述运行信息中的残缺数据和重复数据，并对所述残缺数据进行补全，将所述重复数据删除，获得清洗后的运行信息。

具体的，考虑到由于通过信息获取模块采集到信息并不能很好的符合一线运维的需求，就需要对采集到的信息进行清洗、提取和整合，将各个厂商、品牌不同形式的信息进行统一和规范，更好的为运维工作提供支持。如图3所示，信息处理平台还可以包括信息处理模块。信息处理模块用于将信息获取模块所采集到的运行信息处理成规范格式，并根据运维需要对基础信息进行整理和整合获得运维信息。其中运行信息可以存储于基础信息库，运维信息可以存储于管理信息库。

信息处理模块可以包括数据清洗单元和数据提取整合单元。

针对数据清洗单元，由于网络设备所产生的运行信息中存在大量的无效、重复和缺失信息，例如各类规范性文件中要求的端口描述信息。运维人员手工维护信息时也会带入部分错误，为了维护信息的一致性，我们需要对获取到的信息进行数据清洗。数据清洗模块，用于通过检测脚本获取缺失值的信息，并对残缺信息进行补全。还用于通过检测脚本对基础信息进行周期性检查，自动发现和删除重复数据。

针对数据提取整合单元，在进行运维工作时，各类网络设备信息单独出现并不能够为运维人员提供足够的信息，例如进行IP地址查询时，仅有设备信息并不足够，需要配合应用相关信息才满足运维需求。因此，通过数据提取整合单元可以将各类相关信息进行整合，形成多维度的信息聚合体更有助于运维人员进行判断。本实施例中可以针对网络常见的ARP、MAC、路由、邻居信息等基础运维信息设计相应的提取脚本，并将多份关联数据合并，生成新的表单，然后在新的表单的基础上可以完成查询或者其他关联数据的合并操作。

202、从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备。

203、将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

在一些实施例中，所述将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息，可以包括：基于结构分析算法，构建待检测设备的关联图；根据所述关联图构建待训练图卷积神经网络；获取待检测设备的历史运维数据和关联设备的历史运维数据，并根据所述历史运维数据确定样本集；根据所述样本集对所述待训练图卷积神经网络进行训练，获得故障预测模型；将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

具体的，在网络设备故障预测过程中，设备自身产生的运行信息(例如日志)和相邻设备可能都会产生一定的变化。且由于网络设备的特殊性，设备之间具有一定的差异性，且设备的相邻设备和相邻设备的相邻设备都有可能对设备造成影响，本方案提出一种结合先验知识的图卷积神经网络方法来对故障进行预测。根据收集到的时间序列信息(设备产生的各类运行信息)和设备相关信息对运行中的网络设备进行故障预测。由于设备发生故障是高度非线性的，且很多因素都能造成设备故障，传统故障预测方法主要关注对硬件信息和各类告警的时间特征进行建模，忽略了硬件信息或告警信息之间的空间特征(相邻设备的信息)。

如图3所示，信息处理平台还可以包括故障预测模块。故障预测模块主要采用结合先验知识的图卷积网络的方法进行故障预测。

如图4所示，首先，可以基于预设的网络设备之间的关联关系(示例性的，该预设的关联关系可以根据专家经验进行设定)，将待检测设备的历史运维信息和关联设备(待检测设备的相邻设备，和/或，该相邻设备的相邻设备)的历史运维信息作为样本集。示例性的可以从上述管理信息库和故障事件库中获取。

其次，可以采用结构分析的方式构建图卷积神经网络的关联图。具体的，可以根据预设的网络设备之间的关联关系，列出所有的方程，并将所有的变量分为故障因素、已知因素和未知因素，并寻找因素与方程的关系。进而，可以采用Dulmage-Mendelsohn分解分析故障的可检测性，在具备确定具备可检测性后，可以采用故障隔离矩阵分析故障的隔离性，在确定隔离性达到预设阈值后，可以通过Dulmage-Mendelsohn分解将关联图根据因素和方程的数量机型划分，并通过追加因素的方式使因素数量大于方程数量。进而可以设置故障检查策略，为每个故障设置合适的阈值，从而形成关联图。

在获得关联图后，可以根据关联图构建待训练图卷积神经网络模型。基于样本集对待训练图卷积神经网络进行训练，获得故障预测模型。

在故障预测模型的应用过程中，可以将当前获取的待检测设备的运维信息和关联设备的运维信息，输入故障预测模型，从而可以获得故障提示信息，实现对待检测设备的故障检测。

本实施例提供的故障检测方法，通过将数据中心的多个网络设备中获取其运行信息，并对运行信息进行整合后，获得运维信息，进而可以提取待检测设备和其关联设备的运维信息，并将该运维信息作为故障预测模型的输入，以通过故障预测模型进行预测，获得待检测设备的故障提示信息，不仅通过故障预测模型的应用实现了自动化，还通过结合待检测设备的关联设备的运行情况对待检测设备的故障进行预测提高了故障检测的准确率。

图5为本申请实施例提供的故障检测方法的流程示意图二。如图5所示，在上述实施例的基础上，例如在图2所示实施例的基础上，为了提高加强对网络设备的监控，本实施例中增加了定制化基线核查的过程，并对其进行了详细说明，该方法包括：

501、获取多个网络设备的运行信息，并对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息。

502、从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备。

503、将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

本实施例中步骤501至步骤503，与上述实施例中步骤201至步骤203相类似，此处不再赘述。

504、根据所述配置信息对多个所述网络设备进行基线核查。

在一些实施例中，所述根据所述运维信息对多个所述网络设备进行基线核查，可以包括：根据多个所述网络设备的配置关联关系，确定待核查设备的配置区域的关联区域；根据预设的基线核查规则，对所述配置区域和所述关联区域的配置信息进行基线核查，获得检查结果。

随着网络的普及，对于网络风险的关注度也在逐渐提高。数据中心是信息时代的基础设施，也是网络风险控制的核心与关键，一旦失守，个人信息与商业数据就会遭遇大规模泄露。网络设备是连通整个数据中心的关键路径，因此，如何准确全面的对网络设备的配置定期进行合规检查是十分必要的。

基线检查功能可以进行系统安全加固，降低入侵风险并满足安全合规要求。该功能根据各类监管和行业标准规范对设备配置进行安全实践和合规性检查，包括弱口令、账号权限、身份鉴别、密码策略、访问控制、安全审计和入侵防范等网络设备配置核查。由于网络设备配置信息可能存在于设备配置信息的多处地方，采用上述常规基线核查准确率低，因此本实施例采用可关联查询的规则模式，即可以在设备配置的模块下与设备全局配置进行联动查询，指定关联项即可将全局与部分配置进行关联，例如将全局配置下的绑定信息和端口进行关联，或者将访问控制列表的内容(ACL)信息与端口进行关联，也可以将子接口和物理端口进行信息关联。

本实施例中，在进行基线核查时，可以根据特定的规则对设备配置或设备运行信息进行检查，查看设备是否符合规则的要求。例如检查全局配置信息下是否包含特定的组合式配置，全局和端口下是否配置相关条目使得端口下配置生效，同样通过关系符号的方式实现选择特定进行多条规则联合检查的功能。配置检查功能在进行检查时可以选择直接对配置进行检查或在配置无法直接获取时通过下发命令并获取回显，以对回显进行检查。

示例性的，基线核查可以涉及四个模块：规则模块，关联关系模块，下发命令获取回显匹配模块和规则处理模块。

规则模块用于设置匹配规则，并根据自定义的分割符确认查找指定配置区域内(查找区域)是否存在特定信息，该模块使用关联关系模块指定特定的关联区域(关联区域)，从而跳出查找区域去关联区域寻找相关的信息。

关联关系模块用于通过关联关系连接设备配置中不同区域信息，是本方案中基线核查模块的关键，首先通过自定义分隔符确定关联区域，然后定义关联键，以便通过规则处理模块在关联区域中通过关联键将相关信息进行匹配和关联，最终确定配置是否符合规范。

下发命令获取回显匹配模块用于在无法直接获取到关联区域的配置信息对配置信息检查时，可以通过指定下发命令下发到设备上，获取关联区域的配置信息进而通过规则处理模块将指定的规则与获取回显进行比较来判断是否通过检查。

规则处理模块用于在对某类设备检查时，对检查规则进行处理。该模块主要包含或、和与括号的操作，通过或、和与括号的操作符挑选合适的规则进行整编，完成设备的基线检查工作。

本实施例提供的故障检测方法，通过基于设备之间的关联关系，实现基线核查的定制化，针对网络设备的配置西悉尼可能存在于多个设备的配置信息中的特点，提高了基线核查的效率和准确率。

图6为本申请实施例提供的故障检测设备的结构示意图。如图6所示，该故障检测设备60包括：获取模块601、提取模块602以及预测模块603。

获取模块601，用于获取多个网络设备的运行信息，并对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息；

提取模块602，用于从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备；

预测模块603，用于将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

本申请实施例提供的故障检测设备，通过将数据中心的多个网络设备中获取其运行信息，并对运行信息进行整合后，获得运维信息，进而可以提取待检测设备和其关联设备的运维信息，并将该运维信息作为故障预测模型的输入，以通过故障预测模型进行预测，获得待检测设备的故障提示信息，不仅通过故障预测模型的应用实现了自动化，还通过结合待检测设备的关联设备的运行情况对待检测设备的故障进行预测提高了故障检测的准确率。

本申请实施例提供的故障检测设备，可用于执行上述的方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

图7为本申请实施例提供的故障检测设备的硬件结构示意图，该设备可以是终端设备或服务器，例如计算机，消息收发设备，平板设备，医疗设备等。

设备70可以包括以下一个或多个组件：处理组件701，存储器702，电源组件703，多媒体组件704，音频组件705，输入/输出(I/O)接口706，传感器组件707，以及通信组件708。

处理组件701通常控制设备70的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件701可以包括一个或多个处理器709来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件701可以包括一个或多个模块，便于处理组件701和其他组件之间的交互。例如，处理组件701可以包括多媒体模块，以方便多媒体组件704和处理组件701之间的交互。

存储器702被配置为存储各种类型的数据以支持在设备70的操作。这些数据的示例包括用于在设备70上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器702可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件703为设备70的各种组件提供电力。电源组件703可以包括电源管理系统，一个或多个电源，及其他与为设备70生成、管理和分配电力相关联的组件。

多媒体组件704包括在所述设备70和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件704包括一个前置摄像头和/或后置摄像头。当设备70处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件705被配置为输出和/或输入音频信号。例如，音频组件705包括一个麦克风(MIC)，当设备70处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器702或经由通信组件708发送。在一些实施例中，音频组件705还包括一个扬声器，用于输出音频信号。

I/O接口706为处理组件701和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件707包括一个或多个传感器，用于为设备70提供各个方面的状态评估。例如，传感器组件707可以检测到设备70的打开/关闭状态，组件的相对定位，例如所述组件为设备70的显示器和小键盘，传感器组件707还可以检测设备70或设备70一个组件的位置改变，用户与设备70接触的存在或不存在，设备70方位或加速/减速和设备70的温度变化。传感器组件707可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件707还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件707还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件708被配置为便于设备70和其他设备之间有线或无线方式的通信。设备70可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件708经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件708还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备70可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器702，上述指令可由设备70的处理器709执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上故障检测设备执行的故障检测方法。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

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

获取多个网络设备的运行信息，并对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息；

从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备；

将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

2.根据权利要求1所述的方法，其特征在于，所述获取多个网络设备的运行信息，包括：

获取多个网络设备的元数据；

针对多个所述网络设备中的每个网络设备，若所述网络设备的元数据表明所述网络设备存在采集接口，则通过所述采集接口采集所述网络设备的运行信息；

若所述网络设备的元数据表明所述网络设备不存在采集接口，则基于简单网络管理协议SNMP采集所述网络设备的运行信息；

若基于SNMP采集失败，则根据所述元数据中的设备配置命令，下发命令并获取回显，获得所述网络设备的运行信息。

3.根据权利要求1所述的方法，其特征在于，所述对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息，包括：

对多个所述网络设备的运行信息进行清洗，获得清洗后的运行信息；

根据多个所述网络设备之间的关联关系，对所述清洗后的运行信息进行整合，获得所述多个网络设备的运维信息。

4.根据权利要求3所述的方法，其特征在于，所述对多个所述网络设备的运行信息进行清洗，获得清洗后的运行信息，包括：

确定所述运行信息中的残缺数据和重复数据，并对所述残缺数据进行补全，将所述重复数据删除，获得清洗后的运行信息。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息，包括：

基于结构分析算法，构建待检测设备的关联图；

根据所述关联图构建待训练图卷积神经网络；

获取待检测设备的历史运维数据和关联设备的历史运维数据，并根据所述历史运维数据确定样本集；

根据所述样本集对所述待训练图卷积神经网络进行训练，获得故障预测模型；

将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述运行信息包括多个所述网络设备的配置信息；所述方法还包括：

根据所述配置信息对多个所述网络设备进行基线核查。

7.根据权利要求6所述的方法，其特征在于，所述根据所述运维信息对多个所述网络设备进行基线核查，包括：

根据多个所述网络设备的配置关联关系，确定待核查设备的配置区域的关联区域；

根据预设的基线核查规则，对所述配置区域和所述关联区域的配置信息进行基线核查，获得检查结果。

8.一种故障检测设备，其特征在于，包括：

获取模块，用于获取多个网络设备的运行信息，并对多个所述网络设备的运行信息进行整合，获得所述多个网络设备的运维信息；

提取模块，用于从所述运维信息中提取待检测设备的第一运维信息和关联设备的第二运维信息；所述关联设备为与所述待检测设备具有关联关系的设备；

预测模块，用于将所述第一运维信息和所述第二运维信息输入故障预测模型，获得所述待检测设备的故障提示信息。

9.一种故障检测设备，其特征在于，包括：至少一个处理器和存储器；

所述存储器存储计算机执行指令；

所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1至7任一项所述的故障检测方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至7任一项所述的故障检测方法。

Images