具体实施方式

本发明附图仅用于示例性说明，不能理解为对本发明的限制。随着大数据和云计算等IT环境的发展，企业的IT及其应用环境越来越庞大，越来越复杂，由此不断产生的告警信息数量非常巨大，而且来源多样，在运维故障告警处理中，如果不能进行及时准确的告警收敛，排除无关、重复、不严重的告警干扰，那么运维人员将面临各类各样数量巨大的告警消息，难以第一时间发现根源问题，导致延误故障处理时间，进而给业务运营带来潜在风险和损失。

请参阅图1，图1为本发明实施例提供的一种故障感知模型构建方法的流程图，该方法包括步骤：

S101、将多条告警划分为多个告警组，一个所述告警组包括主告警和多个具有不同优先级的次告警；

在本实施例中，针对海量的告警信息，告警信息中有些由某些相同因素引发的，或者互相之间存在一定关联性，可以将这些告警信息收敛为一条告警信息，当这些告警信息出现时，可以定位为同一告警源引起的告警，比如链路断开告警关联的告警为成员链路协商不成功告警和链路带宽全部丢失告警，当告警出现链路断开时，查询成员链路协商不成功和链路带宽全部丢失的关联信息，当出现成员链路协商不成功告警和链路带宽全部丢失告警的关联信息，则可以定位为链路断开引起的告警。

因此，为了压缩告警信息，有效地减少告警处理的数量，本实施例可以根据不同的业务场景或同一类型的告警类型，将多条告警划分为多个告警组，一个告警组中包括主告警和多个具有不同优先级的次告警，主告警和次告警具有相同的因果关联关系，当主告警产生时，通过判断主告警的类型，快速定位到主告警所在的告警组，在告警组内建立主告警与次告警之间的关联关系，从而快速定位到故障的根本原因。

具体地，本实施例就链路断开这一主告警信息，根据主告警与其它告警的关系，举例提供了两种告警组的划分，

第一，主告警为：链路断开；

次告警为：

a类、“成员链路协商不成功告警”、“LAG协商不成功告警”，

b类、“链路带宽全部丢失告警”、“LAG带宽全部丢失告警”，

c类、“Trunk所有成员口都Down”，

d类、“光模块整体功能失效”、“光模块拔出”。

其中，a类次告警的优先级最高，b类次之，c类最低，a类和d类的优先级相同。

第二，主告警为：链路断开；

a类、“物理端口DOWN”，

b类、“接收线路侧信号丢失”，

c类、“光模块的接收功率过高”、“光模块被拔出”。

其中，a类次告警的优先级最高，b类次之，c类最低。

S102、根据所述主告警与所述次告警之间的关联关系，或者，根据所述主告警与最高优先级的所述次告警之间的关联关系，以及不同优先级的所述次告警之间的关联关系，按照所述次告警的优先级，依次在各个优先级下匹配所述次告警；

若在当前优先级下未匹配到所述次告警，则不继续在下一优先级下匹配所述次告警，并结束匹配所述次告警；

S103、对匹配到的所述次告警与所述主告警进行关联，形成关联规则；

本实施例通过设立关联条件，建立主告警与次告警的关联关系，具体通过设立告警的定位信息中的关联信息来建立关联关系，比如，解析告警为链路断开的定位信息，可以获取接口名称、接口索引等多种信息，解析成员链路协商不成功告警的定位信息，可以获取接口名称、Trunk名称、Trunk索引等多种信息，因此在定位信息中设定关联信息，收到告警并解析其定位信息后可以获取关联信息以此建立告警之间的关联关系。本实施例提供两种告警关联关系的建立，其中一种是在告警组内根据主告警与次告警之间的关联关系，另外一种是根据主告警与最高优先级的次告警之间的关联关系和不同优先级的次告警之间的关联关系。

根据主告警与最高优先级的次告警之间的关联关系和不同优先级的次告警之间的关联关系匹配关联次告警的一种具体实施方式是，所述根据所述主告警与最高优先级的所述次告警之间的关联关系，以及不同优先级的所述次告警之间的关联关系，按照所述次告警的优先级，依次在各个优先级下匹配所述次告警，包括：

预设所述主告警与最高优先级的所述次告警之间的第一关联信息，以及不同优先级的所述次告警之间的第二关联信息；

解析最高优先级的所述次告警的定位信息，若解析到的定位信息包括所述第一关联信息，则匹配到最高优先级的所述次告警；

当匹配到最高优先级的所述次告警后，依次解析下一优先级的所述次告警的定位信息，若解析到的定位信息包括第二关联信息，则所述主告警匹配到下一优先级的次告警，直至结束匹配所述次告警。

本实施例采用上述提到的第一种告警组来说明根据主告警与最高优先级的次告警之间的关联关系和不同优先级的次告警之间的关联关系匹配关联次告警的具体过程为：

首先，预设主告警“链路断开”与a类次告警“成员链路协商不成功告警”、“LAG协商不成功告警”之间的第一关联信息为接口名称A，预设a类次告警、b类次告警、c类次告警之间的第二关联信息为Trunk名称B，这里的Trunk是用于交换机与服务器之间的相联，为服务器提供独享的高带宽；用于交换机之间的级联，为交换机之间的数据交换提供高带宽的数据传输能力，提高网络速度，突破网络瓶颈，进而大幅提高网络性能。

其次，解析a类次告警“成员链路协商不成功告警”、“LAG协商不成功告警”的定位信息，若解析到的定位信息中包括与主告警定位信息相同的第一关联信息接口名称A时，则主告警“链路断开”匹配到a类次告警，并进行关联；若解析到的定位信息中不包括接口名称A，则主告警“链路断开”不匹配关联a类次告警，且匹配关联结束；

在匹配到a类次告警后，解析b类次告警“链路带宽全部丢失告警”、“LAG带宽全部丢失告警”的定位信息，若解析到的定位信息中包括与a类次告警定位信息相同的第二关联信息Trunk名称B时，则主告警“链路断开”匹配到b类次告警，并进行关联；若解析到的定位信息中不包括Trunk名称B时，则主告警“链路断开”不匹配关联b类次告警，且匹配关联到a类次告警即结束；

在匹配到b类次告警后，解析c类次告警“Trunk所有成员口都Down”的定位信息，若解析到的定位信息中包括与a类和/或b类次告警定位信息相同的第二关联信息Trunk名称B时，则主告警“链路断开”匹配到c类次告警，并进行关联；若解析到定位信息不包括Trunk名称B时，则主告警“链路断开”不匹配关联c类次告警，且匹配关联到b类次告警即结束。

根据主告警与次告警之间的关联关系匹配关联次告警的另外一种具体实施方式是，所述根据所述主告警与所述次告警之间的关联关系，包括：

预设所述主告警与所述次告警的第三关联信息；

按照优先级依次解析所述次告警的定位信息，若解析到的定位信息包括所述第三关联信息，则匹配到所述次告警，直至结束匹配所述次告警。

本实施例采用上述提到的第二种告警组来说明根据主告警与次告警之间的关联关系匹配关联次告警的具体过程为：

首先，预设主告警“链路断开”与a类、b类、c类次告警之间的第三关联信息为接口名称A；

其次，解析a类次告警“物理端口DOWN”的定位信息，若解析到的定位信息中包括第三关联信息接口名称A时，则主告警“链路断开”匹配到a类次告警，并进行关联；若解析到的定位信息中不包括接口名称A，则主告警“链路断开”不匹配关联a类次告警，且匹配关联结束；

在匹配到a类次告警后，解析b类次告警“接收线路侧信号丢失”的定位信息，若解析到的定位信息中包括第三关联信息接口名称A时，则主告警“链路断开”匹配到b类次告警，并进行关联；若解析到的定位信息中不包括接口名称A时，则主告警“链路断开”不匹配关联b类次告警，且匹配关联到a类次告警即结束；

在匹配到b类次告警后，解析c类次告警“光模块的接收功率过高”、“光模块被拔出”的定位信息，若解析到的定位信息中包括与第三关联信息接口名称A时，则主告警“链路断开”匹配到c类次告警，并进行关联；若解析到定位信息不包括接口名称A时，则主告警“链路断开”不匹配关联c类次告警，且匹配关联到b类次告警即结束。

S104、根据所述告警组和所述关联规则，构建故障感知模型。

根据不同的业务场景和告警情况，可以按照上述至少一种关联关系设定对应的关联规则并构建故障感知模型，当告警产生时，根据故障感知模型关联主告警与次告警，并执行收敛处理，对收敛后的告警结果进行告警处理。

采用故障感知模型构建方法构建的故障感知模型，在设备系统中执行故障感知方法，请参阅图3，图3为本发明实施例一种故障感知方法的流程图，其方法包括：

S301、当主告警发生时，利用故障感知模型构建方法所构建的故障感知模型，获取与所述主告警关联的次告警；

S302、将关联到的所述次告警进行收敛处理，并对所述主告警和收敛后的所述次告警进行告警处理。

本实施例中，根据构建的故障感知模型，匹配关联到次告警，并对关联到的次告警进行收敛处理，得到收敛后的告警结果，具体地，根据上述提到的两种告警组和两种对应的匹配关联规则，结合告警状态、告警时间等，可对应得到以下两种具体的关联收敛结果为：

第一，主告警为链路断开，关联到a类：“成员链路协商不成功告警”、“LAG协商不成功告警”次告警、b类：“链路带宽全部丢失告警”、“LAG带宽全部丢失告警”次告警、c类：“Trunk所有成员口都Down”次告警；

【告警状态】新增

【告警时间】2021-07-29 10:07:31

【告警标题】链路断开

【设备名称】DEVICE_NAME(DEVICE_IP)

【关联告警】{"成员链路协商不成功告警"，"LAG协商不成功告警","LAG带宽全部丢失告警","Trunk所有成员口都Down","链路带宽全部丢失告警"}

【可能原因】{链接断开}。

第二，主告警为链路断开，关联到a类：“物理端口DOWN”次告警、b类：“接收线路侧信号丢失”次告警、c类：“光模块的接收功率过高”、“光模块被拔出”次告警；

【告警状态】新增

【告警时间】2021-07-29 10:07:31

【告警标题】链路断开

【设备名称】DEVICE_NAME(DEVICE_IP)

【定位信息】物理接口索引＝50,物理接口名称＝10GE1/0/40

【关联告警】{"物理端口DOWN”，"接收线路侧信号丢失"，"光模块的接收功率过高"、“光模块被拔出"}

【可能原因】{链路断开由于光模块被拔出}

在步骤S301中，当主告警发生时，利用所述故障感知模型构建方法所构建的故障感知模型，获取与所述主告警关联的次告警，包括：

所述当主告警发生时，判断所述主告警的告警类型；

若所述告警类型为监控平台告警，则继续判断所述监控平台告警为设备告警或应用告警，得到第一判断结果，利用与所述第一判断结果对应的所述故障感知模型，获取与所述主告警关联的次告警；

若所述告警类型为安全设备告警，则继续判断所述安全设备告警为入侵检测告警或DOS告警或异常行为检测告警或漏掉告警，得到第二判断结果，利用与所述第二判断结果对应的所述故障感知模型，获取与所述主告警关联的次告警。

运维设备系统是一个庞大的数据处理系统，产生的告警信息数据数量是非常巨大的，产生的告警类型也是多样化的，因此，在告警发生之前，针对不同的业务场景或者设备种类等，设定对应的多种告警类型，并根据告警类型建立对应的告警模型，包括故障感知模型，利用故障感知模型对多条告警进行收敛处理，得到收敛结果后执行告警处理。

请参阅图5，图5为告警来源分类的示意图，本实施例具体根据告警设备来源，确定告警的类型，再由告警类型归纳出不同的故障感知模型，每种故障感知模型可对应不同的关联规则，由关联规则确定故障影响范围。因此，当主告警发生时，首先要判断主告警的告警类型，比如告警的是安全设备告警，先判断告警的分类为入侵检测告警或DOS告警或异常行为检测告警或漏掉告警，若是入侵检测，则按预设的扫描攻击的故障感知模型或者暴力破解的故障感知模型，检测告警的攻击IP的地域信息，如果是国外IP，则立即再防火墙进行封堵；如果是国内IP，则根据攻击的频率，一定时间段内频繁扫描或者暴力破解的，按规则进行封堵，告警等级越高，危害性越大，封堵的时间越长。再比如告警的是监控平台的告警，先判断是设备告警还是应用告警，若是设备可用性告警，再根据资源池、集群、宿主机、虚拟机、存储、机箱、电源、温度、风扇、网卡等可用性的预设的故障感知模型，按关联收敛规则，确定故障影响的范围和故障等级。

另外，本实施例还可以根据收集的海量告警和日志，调用机器学习库，用分类、回归算法，构建多种故障感知模型并进行模型融合，预测故障的发生概率。如Windows2008R2系统运行时间超过497天，TCP/IP的网络资源(端口)就不会再自动释放，在运行一段时间后，本机的网络资源就会被全部用光。这样就会造成系统中任何需要网络资源的组件都无法正常工作，必须重启才能正常使用。根据收集的日志告警信息，提取window的版本号，运行时间，网络资源信息，可用预测下次故障的时间。

在步骤S302中，所述对所述主告警和收敛后的所述次告警进行告警处理，包括：根据告警处理时间，将所述主告警和收敛后的所述次告警通过多种通知方式推送至用户终端。

本实施例所说的告警处理是指是对出现的异常进行精准通知，在得出告警结果后，精准快速地通知到用户群体，以便于对故障作出及时的响应维护服务，比如根据某条异常所涉及的客户进行通知，根据异常的类型通知相应的专业人员处理，根据异常等级选择通知的方式等等，本实施例的告警处理支持多渠道通知，包括电话、微信、钉钉、短信、邮件、日历等方式进行通知。

不仅如此，在将告警结果采用多种方式通知用户时，通过查询内部台账系统，找到告警所属客户，而且还能根据告警时间，比如是在白天时段，则首先采用微信通知或者钉钉通知，将监控告警收敛后的告警结果自动推送至客户微信群或者钉钉群。这里所说的微信群或者钉钉群，依据的是网元IP归属的客户，群事先建好。还可以根据故障运维服务协议(SLA)等级，每上升一级，则自动生成汇报信息后，微信或者钉钉汇报上一级领导；比如是在晚上时段，则直接调用电话通知到客户，实现方式具体为通过调用通信平台语音通知的接口，获取被通知者电话号码以及分析数据库的数据，根据数据生成告警文字，该接口会将文字转化成语音，向对象电话终端呼叫，接通电话后，播放告警语音。

本实施例的故障感知模型构建方法和故障感知方法都是基于运维监控故障感知平台上实现的，故障感知平台总体分为四层，资源层、采集层、处理层和呈现层，资源层是基于行业云的云网资源所需检测关联的资源，主要为带内带外监控数据；采集层通过向下采集基础设施的所有信息，进行数据存储；处理层对采集到的数据进行智能检测和智能处理，并精度调度多种渠道对告警信息进行通知；呈现层进行故障分析站视，故障链展示等。

而且，本实施例利用故障感知平台的资源层、采集层、处理层和呈现层搭建模块化的故障感知系统，故障感知系统包括数据汇集模块、智能检测模块和精准调度模块：

其中，数据汇集模块用于，根据业务实际所需，通过监控平台的接口，或者是实时登入设备查看等方式，对带内带外监控系统平台的数据(云主机、物理机、路由器、交换机资源的某个时段连通性、cpu、内存、磁盘使用情况的数据和相应的告警信息)，以及这些网络、存储、主机运行的日志等进行采集，并发送给处理层进行处理。还用于，通过采用rabbitmq(rabbitmq是实现了高级消息队列协议的开源消息代理软件)和restfull http实时接收和请求告警日志数据。告警日志采用消息队列的方式，监控设备一发现告警，立即拉取告警数据并推送出去，数据汇集模块实时接收到告警数据。告警的采集实时性，保障了报警后续处理的及时性。

智能检测模块用于，首先接收到数据汇集模块发送过来的数据后，进行筛选发现有效数据，如告警IP、告警设备、告警内容、告警时间等。根据告警内容和故障感知模型的关联规则，查询关联告警信息并进行收敛处理，然后根据告警IP，关联企业的台账系统，查询告警设备对应的客户信息，至少包括客户电话、客户邮箱、客户名称、业务名称等，再通过精准调度模块采用多渠道进行精准通知。本发明实施例中所说的故障感知方法主要具体体现在平台的智能检测模块中。

除上述提到的故障感知模型构建方法之外，本发明实施例还提供了对应的一种故障感知模型构建系统，请参阅图2，图2为本发明实施例一种故障感知模型构建系统的结构图，其构建系统包括：

分组模块201，用于将多条告警划分为多个告警组，一个所述告警组包括主告警和多个具有不同优先级的次告警；

匹配模块202，用于根据所述主告警与所述次告警之间的关联关系，或者，根据所述主告警与最高优先级的所述次告警之间的关联关系，以及不同优先级的所述次告警之间的关联关系，按照所述次告警的优先级，依次在各个优先级下匹配所述次告警；若在当前优先级下未匹配到所述次告警，则不继续在下一优先级下匹配所述次告警，并结束匹配所述次告警；

关联模块203，用于对匹配到的所述次告警与所述主告警进行关联，形成关联规则；

构建模块204，用于根据所述告警组和所述关联规则，构建故障感知模型。

根据主告警与最高优先级的次告警之间的关联关系和不同优先级的次告警之间的关联关系匹配关联次告警的一种具体实施方式是，在匹配模块202中，具体包括：

预设所述主告警与最高优先级的所述次告警之间的第一关联信息，以及不同优先级的所述次告警之间的第二关联信息；

解析最高优先级的所述次告警的定位信息，若解析到的定位信息包括所述第一关联信息，则匹配到最高优先级的所述次告警；

当匹配到最高优先级的所述次告警后，依次解析下一优先级的所述次告警的定位信息，若解析到的定位信息包括第二关联信息，则所述主告警匹配到下一优先级的次告警，直至结束匹配所述次告警。

根据主告警与次告警之间的关联关系匹配关联次告警的另外一种具体实施方式是，在匹配模块202中，具体包括：

预设所述主告警与所述次告警的第三关联信息；

按照优先级依次解析所述次告警的定位信息，若解析到的定位信息包括所述第三关联信息，则匹配到所述次告警，直至结束匹配所述次告警。

除上述提到的故障感知方法之外，本发明实施例还提供了对应的一种故障感知系统，请参阅图4，图4为本发明实施例一种故障感知方法的结构图，其故障感知系统包括：

获取关联模块401，用于当主告警发生时，利用所述的故障感知模型构建方法所构建的故障感知模型，获取与所述主告警关联的次告警；

收敛告警模块402，用于将关联到的所述次告警进行收敛处理，并对所述主告警和收敛后的所述次告警进行告警处理。

对于获取关联模块401，具体包括：

所述当主告警发生时，判断所述主告警的告警类型；

若所述告警类型为监控平台告警，则继续判断所述监控平台告警为设备告警或应用告警，得到第一判断结果，利用与所述第一判断结果对应的所述故障感知模型，获取与所述主告警关联的次告警；

若所述告警类型为安全设备告警，则继续判断所述安全设备告警为入侵检测告警或DOS告警或异常行为检测告警或漏掉告警，得到第二判断结果，利用与所述第二判断结果对应的所述故障感知模型，获取与所述主告警关联的次告警。

对于收敛告警模块402，具体包括：根据告警处理时间，将所述主告警和收敛后的所述次告警通过多种通知方式推送至用户终端。

本发明实施例还提供一种电子设备，包括处理器和存储器，所述存储器存储有计算机程序，所述处理器被设置成运行所述计算机程序以执行所述的一种故障感知模型构建方法，或如所述的一种故障感知方法。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个计算机程序，所述计算机程序被设置为运行时执行所述的一种故障感知模型构建方法，或所述的一种故障感知方法。

显然，本发明的上述实施例仅仅是为清楚地说明本发明技术方案所作的举例，而并非是对本发明的具体实施方式的限定。凡在本发明权利要求书的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。