CN111130868A - 一种处理故障信息的方法及相关设备 - Google Patents

Abstract

本发明公开了一种处理故障信息的方法及相关设备，该方法包括：若第一装置确定第一装置与第二装置断开连接，第一装置采集故障信息；第一装置向第三装置发送故障信息，该故障信息用于第四装置确定第一装置与第二装置断开连接的故障原因。第四装置接收故障信息，第四装置根据故障信息确定第一装置与第二装置断开连接的故障原因。这样可以及时的确定故障原因，不需要运维人员手动排查故障原因，对于运维人员的要求较低。

Description

一种处理故障信息的方法及相关设备

技术领域

本发明涉及网络领域，具体涉及一种处理故障信息的方法及相关设备。

背景技术

传统的网络监控方式包括简单网络管理协议(simple network managementprotocol，SNMP)get和命令行界面(command line interface，CLI)，该两种网络监控方式都是通过拉模式(pull mode)获取设备监控数据，如接口流量。但是不能监控大量网络节点，从而限制了网络增长。

通过拉模式来获取设备监控数据，但是不能监控大量网络节点，限制了网络增长。SNMP trap和系统日志(SYSLOG)虽然是推模式(push mode)的，能够在设备产生告警和时间时及时推送数据，然而其推送的数据都是告警或者事件，不同厂商的数据格式不同，采集器对于不同数据的分析难度较大。随着网络监控技术的发展，遥测术(telemetry)解决了这些问题，telemetry技术一项远程从物理设备或虚拟设备上高速采集数据的技术。设备通过推模式主动从采集器上送设备的数据信息，提供实时高速的数据采集功能。

在采用telemetry技术的设备中，在设备正常的情况下，telemetry可以根据用户订阅配置上送订阅信息。但是当设备的上送通道故障时，设备与采集器之间的连接中断，telemetry不能正常上送采集的设备信息到采集器。此时，运维人员虽然能够知道哪一台设备出现问题，但是无法知道是由于什么原因出现的问题。需要通过命令行去排查设备是由于什么原因发生故障的。这种方式对运维人员要求较高，需要运维人员熟练掌握各种命令。

发明内容

本申请实施例提供了一种处理故障信息的方法及相关设备，该方法中，当第一装置与第二装置断开连接之后，该第一装置可以采集故障信息，第四装置可以根据该故障信息确定故障原因，而不需要运维人员通过命令行手动排查故障原因。

有鉴于此，本申请第一方面提供了一种处理故障信息的方法，该方法包括：若第一装置确定第一装置与第二装置断开连接，该第一装置采集故障信息；第一装置向第三装置发送故障信息，该故障信息用于第四装置确定第一装置与第二装置断开连接的故障原因。这种方法不需要运维人员手动排查故障原因，可以降低对运维人员的要求。可以更加方便快捷的获取故障原因。

可选的，结合第一方面，在第一方面的第一种可能的实现方式中，第一装置向第三装置发送故障信息之前，方法还包括：第一装置确定第三装置。该第一装置可以先确定第三装置，然后将故障信息发送至第三装置。

可选的，结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，第一装置确定第三装置包括：第一装置根据预先配置的第三装置的地址确定第三装置。该第一装置上可以预先配置有第三装置的地址，通过该预先配置的第三装置的地址就可以将故障信息发送给该第三装置。

可选的，结合第一方面的第一种可能的实现方式，在第一方面的第三种可能的实现方式中，第一装置确定第三装置包括：第一装置根据地址解析协议ARP表中记录的地址确定第三装置。该第三装置可以通过ARP表中记录的地址确定第三装置，从而将该故障信息发送给第三装置。

本申请第二方面提供了一种处理故障信息的方法，该方法包括：第四装置从第三装置接收故障信息，该故障信息用于指示第一装置与第二装置断开连接；第四装置根据故障信息确定第一装置与第二装置断开连接的故障原因。该第四装置可以在接收到故障信息之后确定第一装置和第二装置断开连接的故障原因。不需要运维人员手动排查故障原因，可以降低对运维人员的要求。可以更加方便快捷的获取故障原因。

可选的，结合第二方面，在第二方面的第一种可能的实现方式中，第四装置根据故障信息确定第一装置与第二装置断开连接的故障原因包括：第四装置根据故障信息以及预测模型确定第一装置与第二装置断开连接的故障原因。该第四装置可以根据预测模型与故障信息确定第一装置和第二装置断开连接的故障原因，和人工排查相比可以提高排查出的故障原因的准确性。

本申请第三方面提供了一种处理故障信息的装置，该装置包括确定模块，用于确定第一装置与第二装置断开连接；采集模块，用于当确定模块确定第一装置与第二装置断开连接时，采集故障信息；发送模块，用于向第三装置发送故障信息，故障信息用于第四装置确定第一装置与第二装置断开连接的故障原因。使用这种装置不需要运维人员手动排查故障原因，可以降低对运维人员的要求。可以更加方便快捷的获取故障原因。

可选的，结合第三方面，在第三方面的第一种可能的实现方式中，确定模块，还用于确定第三装置。

可选的，结合第三方面的第一种可能的实现方式，在第三方面的第二种可能的实现方式中，确定模块，还用于根据预先配置的第三装置的地址确定第三装置。

可选的，结合第三方面的第一种可能的实现方式，在第三方面的第三种可能的实现方式中，确定模块，还用于根据地址解析协议ARP表中记录的地址确定第三装置。

本申请第四方面提供了一种处理故障信息的装置，装置包括：接收模块，用于从第三装置接收故障信息，故障信息用于指示第一装置与第二装置断开连接；确定模块，用于根据故障信息确定第一装置与第二装置断开的故障原因。使用这种装置不需要运维人员手动排查故障原因，可以降低对运维人员的要求。可以更加方便快捷的获取故障原因。

可选的，结合第四方面，在第四方面的第一种可能的实现方式中，确定模块，还用于根据故障信息以及预测模型确定第一装置与第二装置断开的故障原因。

本申请实施例提供了一种处理故障信息的方法及相关设备，该方法包括：若第一装置确定第一装置与第二装置断开连接，第一装置采集故障信息；第一装置向第三装置发送故障信息，故障信息用于第四装置确定第一装置与第二装置断开连接的故障原因。这样可以及时的确定故障原因，而不需要运维人员手动排查故障原因，对于运维人员的要求较低。

附图说明

图1为本申请实施例提供的一种断开连接的故障场景示意图；

图2为本申请实施例提供的一种处理故障信息的方法的一个实施例示意图；

图3为本申请实施例提供的一种处理故障信息的方法的一个场景示意图；

图4为本申请实施例提供的一种处理故障信息的装置的一个实施例示意图；

图5为本申请实施例提供的一种处理故障信息的装置的一个实施例示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。

传统的网络监控方式包括SNMP get和CLI，该两种网络监控方式都是通过拉模式获取设备监控数据，如接口流量。但是不能监控大量网络节点，从而限制了网络增长。

通过拉模式来获取设备监控数据，但是不能监控大量网络节点，限制了网络增长。SNMP trap和SYSLOG虽然是push mode的，能够在设备产生告警和时间时及时推送数据，然而其推送的数据都是告警或者事件，不同厂商的数据格式不同，采集器对于不同数据的分析难度较大。随着网络监控技术的发展，telemetry解决了这些问题，telemetry技术一项远程从物理设备或虚拟设备上高速采集数据的技术。设备通过推模式主动从采集器上送设备的数据信息，提供实时高速的数据采集功能。下表提供了几种相关技术：

请参见图1，在采用telemetry技术的设备中，在设备正常的情况下，telemetry可以根据用户订阅配置上送订阅信息。例如，设备102与采集器104之间是正常连接的，该设备102可以向采集器104上送订阅信息。但是当设备的上送通道故障时，设备与采集器之间的连接中断，telemetry不能正常上送采集的设备信息到采集器。例如设备101与采集器103之间断开连接了，设备101就不能正常上送采集的设备信息到采集器103。此时，运维人员虽然能够知道哪一台设备出现问题，但是无法知道是由于什么原因出现的问题。需要通过命令行去排查设备是由于什么原因发生故障的。这种方式对运维人员要求较高，需要运维人员熟练掌握各种命令。

所以，本申请实施例一提供了一种处理故障信息的方法，请参见图2，在该方法中，该第一装置、第二装置和第三装置为路由器，第四装置为分析器。该方法包括：

201、第一装置确定第一装置与第二装置断开连接。

第一装置确定第一装置与第二装置之间的连接断开。

需说明的是，在第一装置的openconfig-telemetry.yang模型中，配置设备故障时需要上送的故障信息采集组(sensor_group)，sensor_group是结合运维人员的经验，设置相关的故障路径集(路径集主要为xpath)。

其中sensor_group的格式如下：

sensor-paths的路径主要包括两个元素：path和exclude-filter。

path包括如下三种格式：

1.huawei-ifm:ifm/interfaces/interface/ifStatistics：可以统计接口的收发包情况，从而可以进一步判断分析是否由于第一装置硬件性能、软件漏洞(bug)或者网络链接阻塞等导致的第一装置与采集器之间的断开连接。

2.huawei-devm:devm/cpuInfos/cpuInfo：可以查看于中央处理器(centralprocessing unit，CPU)的使用率，从而确定是否是由于CPU使用率过高，导致设备没有能力处理数据包从而导致断开连接。

3.huawei-devm:devm/memoryInfos/memoryInfo：可以查看内存使用率，从而可以确定是否由于内存使用率过高，导致设备没有能力处理数据包。

导致断开连接exclude-filter主要用于对path路径进行条件过滤，示例性的，格式如下(op-field field op-type op op-value value):

op-field systemCpuUsage op-type gt op-value 60

在采集设备中huawei-devm:devm/cpuInfos/cpuInfo路径下的信息时，当该信息中包含的systemCpuUsage的使用率大于60时才上报信息到采集器。当使用率大于60时可以认为systemCpuUsage的使用率过高。需说明的是，60仅为举例，并不能作为限制，该值可以设置为其他值。

202、第一装置采集故障信息。

当步骤201中第一装置确定第一装置与第二装置之间断开连接之后，该第一装置采集故障信息。该故障信息可以包括步骤201中所述的三种格式path。

需说明的是，在该第一装置在步骤201中确定第一装置与第二装置之间断开连接之后，该第一装置可以再次向第一装置发起建立连接。当该第一装置确定连接失败次数大于预设连接失败次数时，该第一设备采集故障信息。示例性的，该预设连接失败次数为5次，该第一设备发起建立连接失败大于或等于5次时，该第一设备采集故障信息。

203、第一装置向第三装置发送故障信息。

第一装置向第三装置发送该故障信息。

需说明的是，该第三装置的地址可以为预先配置在第一装置本地的，也可以为该第一装置根据预先设置的策略确定的。

在一种实施方式中，该第三装置的网际互连协议(internet protocol,IP)地址和端口号(port)。当第一装置与第二装置断开连接时，该第一装置向预先设置的IP地址和端口号发送该故障信息。

在另一种实施方式中，该第三装置预先设置的策略确定第三装置。示例性的，第一装置可以通过预先设置的软件模块查询该第一装置的地址解析协议(address resolutionprotocol，ARP)表，并获取该ARP表中临近设备的IP地址。通过谷歌远程过程调用(googleremote procedure call protocol，GRPC)协议向该ARP表中距离最近的设备发送连接请求。若连接不成功，再向与ARP表中距离排第二的设备发送连接请求。直到连接成功为止，若该第一装置与ARP表中的一个设备连接成功，该第一装置可以确定该设备为第三装置。

若该第三装置的地址是预先配置在第一装置本地的，在第一装置的openconfig-telemetry.yang模型中，需要配置有目标组(destion_group)，该目标组包括该第三装置的IP地址和端口号，该destion_group的定义如下：

当第一装置在步骤202中检测到与第二装置断开连接之后，当该第一装置确定与第二装置的连接失败次数大于预设连接失败次数之后，该第一装置与第三装置建立连接。该第一装置启动huawei-telemetry.yang中fault-device-policy节点中定义的策略采集故障信息。并将故障信息通过dial-out的方式发送给第三装置的sever监听端口。在这种情况下，该第三装置相当于该第一装置的采集器。具体的，该第一装置通过如下代码实现上述步骤：

204、第三装置向第四装置发送故障信息。

当第三装置接收到该故障信息之后，会向第四装置发送该故障信息。需说明的是，该第三装置为路由器设备，该第四装置为分析器。在该路由器设备和分析器之间还设置有采集器。也就是说，该第三装置先将故障信息发送给该采集器，然后该采集器再将该故障信息发送至第四装置。

在该第三装置的openconfig-telemetry.yang中，配置有第一装置的采集路径(senor_group)以及监听接口。当该第三装置的监听端口接收到第一装置发送的数据时，会启动Huawei-telemetry.yang中selected-device-policy节点定义的采集策略，采集故障设备发送来的故障信息，并上送给采集器。具体的，该第三装置通过如下代码实现上述步骤：

需说明的是，第一装置与第三装置之间采用GRPC协议交互，GRPC协议是通过protocol buffers编码格式承载数据的，因此，需要使用protocol buffers定义交互的内容dial_out.proto。

该dial_out.proto的内容可以包括：

该GRPC调用过程为现有技术，此处不再赘述。

205、第四装置根据故障信息确定第一装置和第二装置断开连接的故障原因。

第四装置在从第三装置接收到该故障信息之后，根据该故障信息确定故障原因。具体的，该第四装置中设置有能够预测设备故障的模型，该模型可以为支持向量机(support vector machine，SVM)的机器学习算法训练预测模型，该模型能够对故障信息进行分类，并得到预测结果。该模型机器学习处理流程可以包括：对训练数据集中的数据进行预处理、根据处理后的数据训练预测模型并得到预测模型、对预测模型进行验证。当该第四装置接收到故障信息时，该第四装置可以根据预测模型得到预测结果。

示例性的，该预测模型可以包括运维人员总结的分组传送网(packet transportnetwork，PTN)900板告警手册中的部分故障信息进行了概括。抽取了其中X32主控板告警、X24主控板告警和处理板告警三个部分的内容。当该第四装置接收到故障信息时，该第四装置可以通过训练出的机器学习模型，分析该第一装置是由于步骤201中提及的哪一种故障导致与第二装置断开连接的。

该第四装置训练预测模型的过程主要包括如下步骤：

1.数据特征抽取：

根据X32主控板告警、X24主控板告警和处理板告警三个问题日志可知，对于错误一般会包含fail、abnormal、alarm和err4个关键词。X32主控板告警主控板告警主要有以下关键词fmea-125M、fmea-25M、fmea-phy_alm_harderr_1等关键词,X24主控板告警存在chk-50M_clock，chk-25M_clock、156m_clkchip_pll_and_los等关键词，处理板告警存在Admin-VS-CID＝0x807f04be、80018_spi、38Mclk等关键词。因此，对于需要抽取每种告警的专有名词，是否包含fail abnormal和err，是否存在alarm等关键词，是否存在告警的属性值(如ret_value/reg_va等)。

2.训练模型：

训练采集的训练样例，其中训练集和验证级可以按照一定的比例。示例性的，训练集：验证级＝8:2。使用SVM训练出SVM模型。其中80％用于训练预测模型，20％用于对预测模型进行验证。示例性的，可以计算精确率(precision)、召回率(recall)以及准确率(accuracy)确定训练模型的好坏。

3.预测模型：

当该第四装置接收到第三装置发送的故障信息之后，会根据故障信息的内容，通过预测模型进行预测。当该第四装置预测到设备故障的原因时，该第四装置对该故障原因进行展示，以提示运维人员出现故障的原因，运维人员可以针对该故障原因解决问题。

可以参照图3，该第一装置为设备301，第二装置为采集器303，第三装置为设备302，第四设备为分析器305。当该设备301确定该设备301与采集器303之间断开连接时，该设备301采集故障信息，并将该故障信息发送至设备302，该设备302通过采集器304将故障信息转发至分析器305。需说明的是，在这个处理故障信息的系统里面还可以包括控制器306，当分析器305确定该设备301与设备302之间断开连接的故障原因之后，该分析器305可以将该故障原因上报给控制器306。该控制器306可以存储或者展示该故障原因，具体不做限制。该采集器303与采集器304可以为同一个采集器也可以为不同的采集器，此处不做限制。

本申请实施例一提供了一种处理故障信息的方法及相关设备，该方法包括：若第一装置确定第一装置与第二装置断开连接，第一装置采集故障信息；第一装置向第三装置发送故障信息，故障信息用于第四装置确定第一装置与第二装置断开连接的故障原因。这样可以及时的确定故障原因，而不需要运维人员手动排查故障原因，对于运维人员的要求较低。

本申请实施例二提供了一种处理故障信息的装置，请参照图4，该装置40为实施例一中所述的第一装置，该装置40包括：

确定模块401，用于确定第一装置与第二装置断开连接。

该确定模块401，还用于确定第三装置。

该确定模块401，还用于根据预先配置的第三装置的地址确定第三装置。

该确定模块401，还用于根据地址解析协议ARP表中记录的地址确定第三装置。

采集模块402，用于当确定模块401确定第一装置与第二装置断开连接时，采集故障信息

发送模块403，用于向第三装置发送故障信息，故障信息用于第四装置确定第一装置与第二装置断开连接的故障原因。

本申请第三方面提供了一种处理故障信息的装置，请参见图5，该装置50为实施例一中的第四装置，该装置50可以包括：

接收模块501，用于从第三装置接收故障信息，故障信息用于指示第一装置与第二装置断开连接。

确定模块502，用于根据故障信息确定第一装置与第二装置断开的故障原因。

该确定模块502，还用于根据故障信息以及预测模型确定第一装置与第二装置断开的故障原因。

以上对本发明实施例所提供的一种处理故障信息的方法及相关设备进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (12)

1.一种处理故障信息的方法，其特征在于，所述方法包括：

若第一装置确定所述第一装置与第二装置断开连接，所述第一装置采集故障信息；

所述第一装置向第三装置发送所述故障信息，所述故障信息用于第四装置确定所述第一装置与所述第二装置断开连接的故障原因。

2.根据权利要求1所述的方法，其特征在于，所述第一装置向第三装置发送所述故障信息之前，所述方法还包括：

所述第一装置确定所述第三装置。

3.根据权利要求2所述的方法，其特征在于，所述第一装置确定所述第三装置包括：

所述第一装置根据预先配置的所述第三装置的地址确定所述第三装置。

4.根据权利要求2所述的方法，其特征在于，所述第一装置确定所述第三装置包括：

所述第一装置根据地址解析协议ARP表中记录的地址确定所述第三装置。

5.一种处理故障信息的方法，其特征在于，所述方法包括：

第四装置接收故障信息，所述故障信息用于指示第一装置与第二装置断开连接；

所述第四装置根据所述故障信息确定所述第一装置与所述第二装置断开连接的故障原因。

6.根据权利要求5所述的方法，其特征在于，所述第四装置根据所述故障信息确定所述第一装置与所述第二装置断开连接的故障原因包括：

所述第四装置根据所述故障信息以及预测模型确定所述第一装置与所述第二装置断开连接的故障原因。

7.一种处理故障信息的装置，其特征在于，所述装置包括：

确定模块，用于确定第一装置与第二装置断开连接；

采集模块，用于当所述确定模块确定所述第一装置与所述第二装置断开连接时，采集故障信息；

发送模块，用于向第三装置发送所述故障信息，所述故障信息用于第四装置确定所述第一装置与所述第二装置断开连接的故障原因。

8.根据权利要求7所述的装置，其特征在于，

所述确定模块，还用于确定所述第三装置。

9.根据权利要求8所述的装置，其特征在于，

所述确定模块，还用于根据预先配置的所述第三装置的地址确定所述第三装置。

10.根据权利要求8所述的装置，其特征在于，

所述确定模块，还用于根据地址解析协议ARP表中记录的地址确定所述第三装置。

11.一种处理故障信息的装置，其特征在于，所述装置包括：

接收模块，用于接收故障信息，所述故障信息用于指示第一装置与所述第二装置断开连接；

确定模块，用于根据所述故障信息确定所述第一装置与所述第二装置断开的故障原因。

12.根据权利要求11所述的装置，其特征在于，

所述确定模块，还用于根据所述故障信息以及预测模型确定所述第一装置与所述第二装置断开的故障原因。

Images