CN107239388A - 一种监测告警方法及*** - Google Patents

Abstract

本申请公开了一种监测告警方法及***，包括：获取监测数据；利用监测模型分析监测数据，得到分析结果；判断分析结果是否满足预设条件；如果满足，则进行告警；其中，监测模型为基于Spark框架，利用历史监测数据，得到故障发生概率与历史监测数据的第一对应关系，利用第一对应关系，得到监测模型。本发明通过获取监测对象的监测数据，利用基于Spark框架，通过历史监测数据得到故障发生概率与历史监测数据的对应关系，制作而成的监测模型对监测数据进行分析，得到分析结果，再判断分析结果是否满足预设条件，如果满足预设条件，则告警，综上所述，实现了在故障发生前，依据当前数据分析出可能发生的故障并提前告警，从而避免故障的发生或扩大。

Description

一种监测告警方法及***

技术领域

本发明涉及大数据分析领域，特别涉及一种监测告警方法及***。

背景技术

随之科技的进步，大数据分析被应用到各个领域，大规模的监测***也适用于大数据分析领域。

Spark是由加州伯克利大学AMP实验室开发的分布式并行计算框架，主要特点是弹性分布式数据集，中间输出结果可以保存在内存中，节省了大量的磁盘I/O操作。除此之外还支持多次迭代计算，特别适合流计算和图计算。

传统的监控告警方案一般是使用Ganglia+Nagios，收集***和网络的各种数据日志，加以分析，上报故障警告。但是此种传统的监控告警方式有许多弊端。首先监控日志数据量非常大，但是能被运维人员利用到的只有一小部分，大部分数据占据存储空间但没有被利用。其次告警准确度和效率低下，通常告警需要工程师设置告警条件，但是条件的粒度很难把握，这样的告警机制很死板，尤其是针对复杂的业务监控，告警经常漏报和误报。最后传统的运监***只能被动的提示故障，却不能主动的规避故障，这往往让用户处在很被动的状态。

因此，如何能够在故障发生前进行告警，规避故障，成为了研究难点。

发明内容

有鉴于此，本发明的目的在于提供一种监测告警方法及***，在故障发生前提前告警，从而提醒用户进行维护和关注，进而避免故障的发生或扩大。其具体方案如下：

一种监测告警方法，包括：

获取监测数据；

利用监测模型分析所述监测数据，得到分析结果；

判断所述分析结果是否满足预设条件；

如果满足，则进行告警；

其中，所述监测模型为基于Spark框架，利用历史监测数据，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

可选的，所述监测数据包括监测日志和运维人员的操作日志。

可选的，所述监测模型创建过程，包括：

对所述历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

可选的，所述监测模型训练过程，还包括：

对所述历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障与所述历史监测数据的第二对应关系，利用所述第二对应关系，得到所述监测模型。

可选的，还包括：

接收用户输入的过滤列表；

停止对所述过滤列表中记录的故障告警。

可选的，还包括：

利用历史告警信息，分析出高频告警列表；

按照预设频率获取与所述高频告警列表中记录的故障相应的目标监测数据。

可选的，所述利用历史告警信息，分析出高频告警列表的过程，包括：

利用所述历史告警信息的告警次数、告警位置和告警时间，分析出高频告警信息；

接收用户输入的确定信息，并利用所述高频告警信息，得到所述高频告警列表。

本发明还公开了一种监测告警***，包括：

获取模块，用于获取监测数据；

分析模块，用于利用监测模型分析所述监测数据，得到分析结果；

判断模块，用于判断所述分析结果是否满足预设条件；

告警模块，用于如果满足，则进行告警；

其中，所述监测模型为基于Spark框架，利用历史监测数据，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

可选的，所述分析模块，包括：

监测模型创建单元，用于对所述历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

可选的，还包括：

告警分析模块，用于利用历史告警信息，分析出高频告警列表；

高频数据获取模块，用于按照预设频率获取与所述高频告警列表中记录的故障相应的目标监测数据。

本发明中，监测告警方法，包括：获取监测数据；利用监测模型分析监测数据，得到分析结果；判断分析结果是否满足预设条件；如果满足，则进行告警；其中，监测模型为基于Spark框架，利用历史监测数据，得到故障发生概率与历史监测数据的第一对应关系，利用第一对应关系，得到监测模型。本发明获取监测对象的监测数据，利用基于Spark框架，利用历史监测数据，得到故障发生概率与历史监测数据的对应关系，利用对应关系，制作而成的监测模型对监测数据进行分析，得到分析结果，在判断分析结果是否满足预设条件，决定是否告警，如果满足预设条件，则告警，综上所述，实现主动告警，即，在故障发生前，依据当前数据分析出可能发生的故障提前告警，从而提醒用户进行维护和关注，进而避免故障的发生或扩大。

附图说明

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

图1为本发明实施例公开的一种监测告警方法流程示意图；

图2为本发明实施例公开的一种监测告警***结构示意图。

具体实施方式

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

本发明实施例公开了一种监测告警方法，参见图1所示，该方法包括：

步骤S11：获取监测数据。

可以理解的是，为能对监测对象进行主动告警分析，可以详细的获取监测对象的各种基础数据，并根据监测对象的变更获取相应的监测数据，例如，监测对象可以为服务器，相应的获取监测数据也可以根据实际应用需求定时获取监测数据，例如，每隔10分钟获取一次监测对象的监测数据，当然，也可以实时获取监测对象的监测数据。

步骤S12：利用监测模型分析监测数据，得到分析结果。

具体的，监测模型为预先建立好的模型，在监测过程中可以直接调用，利用监测模型分析监测数据，得到分析结果以用于后续告警操作。

其中，监测模型为基于Spark框架制作而成的，利用历史监测数据，基于Spark框架进行多次迭代计算，得到故障发生概率与历史监测数据的第一对应关系，利用第一对应关系，得到监测模型。

可以理解的是，监测模型在分析当前监测数据时的过程与训练时的过程相同，对监测模型进行何种训练，在分析过程中便进行何种分析；可以利用Gnglia获取监测数据。

需要说明的是，监测模型可以不断地利用接收到的监测数据进行学习和更新，从而不断地增加告警的效率和准确度。

步骤S13：判断分析结果是否满足预设条件。

具体的，可以利用分析结果中利用监测数据分析出的故障发生概率判断是否满足预设概率，如果一项故障发生概率超过预设概率，则判定满足预设条件，例如，故障发生概率为50％，预设概率即预设条件为40％，则当前故障发生概率超过预设条件，判定满足预设条件，当然，如果故障发生概率不满足预设条件则不进行操作。

可以理解的是，由于分析结果中包括多种故障的故障发生概率，因此相应的预设条件也可以与故障一一对应，即，用户可以对每个故障判断是否告警的预设条件分别设定，例如，共有第一故障、第二故障和第三故障，用户可以分别对第一故障、第二故障和第三故障设定第一预设条件、第二预设条件和第三预设条件，其中，第一预设条件、第二预设条件和第三预设条件的设置可以不同。

步骤S14：如果满足，则进行告警。

具体的，当分析结果中的故障发生概率满足预设条件，则进行告警；其中，告警方式可以为蜂鸣告警或提示灯告警，也可以像用户的移动终端发送提示信息进行告警，在此不对告警的形式做限定；可以利用Nagios进行告警。

可见，本发明实施例中通过获取监测对象的监测数据，利用历史监测数据，得到故障发生概率与历史监测数据的对应关系，利用对应关系并基于Spark框架制作而成的监测模型对监测数据进行分析，得到分析结果，再判断分析结果是否满足预设条件，决定是否告警，如果满足预设条件，则告警，综上所述，实现了主动告警，即，在故障发生前，依据当前数据分析出可能发生的故障并提前告警，从而提醒用户进行维护和关注，避免了故障的发生或扩大。

本发明实施例公开了一种具体的监测告警方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体的：

步骤S21：获取监测日志和运维人员的操作日志。

具体的，监测数据可以为监测日志和运维人员的操作日志，监测日志中包括监测对象的各种监测数据，操作日志中记载有运维人员进行的各种操作记录，例如，维护记录等。

步骤S22：利用监测模型分析监测数据，得到分析结果。

其中，监测模型可以通过对历史监测日志和历史操作日志中的数据逐条进行SQL(Structured Query Language，结构化查询语言)统计分析，并将具有联系的数据建立关联，得到故障发生概率与历史监测数据的对应关系，利用对应关系得到。

具体的，利用SQL将历史监测日志和历史操作日志进行数据库化，按照数据的属性进行分类，并且从中分析出关键数据，建立具有联系的数据之间的关联，结合历史操作日志和历史监测日志可以分析出故障与监测日志中的那些数据相关，以使根据一个引发故障的数据的变化，可以推算出另一个引发故障的数据的变化，从而实现对故障的预测。

例如，将历史操作日志中的运维人员对故障的维护记录中进行的操作，在同一时段和地点引起的历史监测日志中变化的监测数据相关联，可以得知那些数据与故障相关，从而根据分析这些与故障相关的关键数据，根据部分关键数据的变化可以推算出故障发生概率，得到故障发生概率与历史监测数据的对应关系。

可以理解的是，监测模型在分析当前监测日志和操作日志的过程，与训练时进行的分析过程相同。

步骤S23：判断分析结果是否满足预设条件。

步骤S24：如果满足，则进行告警。

本发明实施例中，上述监测模型训练过程，还可以包括对历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障与历史监测数据的第二对应关系，利用第二对应关系，得到监测模型，通过训练出监测数据与故障的直接关系，为被动告警作出前提保证，被动告警即当故障发生时告警。

进一步的，可以对告警进行分类，将通过监测数据可以直接分析出的告警划分为基本告警，将需要通过多种监测数据组合推算出的告警划分为业务告警，因此，业务告警与基本告警存在一定的关系，即业务告警由一个或多个基本告警引起，业务告警与基本告警存在一定的继承关系，这样在告警时，通过区分基本告警和业务告警，可以使用户更能直观的分析出当前故障所在和故障的严重性。

在实际应用中，一些告警可能影响不大，例如，一些基本告警，且一些较大的故障可能会突然出现大量的告警，例如，一个业务告警级别的故障同时会引起大量基本告警级，过多的告警可能会影响用户的判断，因此，还可以接收用户输入的过滤列表；停止对过滤列表中记录的故障告警，实现对告警的筛选。

需要说明的是，过滤列表可以只是不对表中的故障不进行告警，而监测模型仍对过滤列表中的故障相应的监测数据进行监测和分析，当出现在过滤列表中的故障基础上引发的故障发生概率过高或发生故障，需要告警时则仍然告警，确保能够及时提醒用户保证安全，提高用户体验。

例如，一个业务告警，包括3个基本告警，过滤列表屏蔽了该业务告警的3个基本告警，当3个基本告警对应的任一故障出现，则不会产生与该故障对应的基本告警，但当3个基本告警对应的故障出现，导致业务告警的发生几率超过预设条件，则仍进行与业务告警相应的告警。

可以理解的是，一些故障可能常常频繁出现，通常的监测数据获取频率可能无法及时监测到此类故障，因此，可以对此类故障进行重点关注和监控，具体可以包括步骤S25和步骤S26；

S25：利用历史告警信息，分析出高频告警列表。

具体的，可以利用历史告警信息的告警次数、告警位置和告警时间，分析出高频告警信息，再接收用户输入的确定信息，可以由用户做出最终决定，判断分析出的高频告警信息，是否需要关注，并利用高频告警信息，得到高频告警列表。

S26：按照预设频率获取与高频告警列表中记录的故障相应的目标监测数据。

具体的，在分析出高频告警列表后，用户可以单独设定获取高频告警列表中记录的故障相应的目标监测数据的预设频率，例如，通用监测数据获取频率为每12小时获取一次，预设频率可以设定为每1小时获取一次，也可以设定为实时获取。

相应的，本发明实施例还公开了一种监测告警***，参见图2所示，该***包括：

获取模块11，用于获取监测数据。

具体的，监测数据可以包括监测日志和运维人员的操作日志。

分析模块12，用于利用监测模型分析监测数据，得到分析结果。

其中，监测模型为基于Spark框架，利用历史监测数据，得到故障发生概率与历史监测数据的第一对应关系，利用第一对应关系，得到监测模型。

判断模块13，用于判断分析结果是否满足预设条件。

告警模块14，用于如果满足，则进行告警。

本发明实施例中，上述分析模块12，具体可以包括监测模型创建单元，其中，

监测模型创建单元，用于对历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障发生概率与历史监测数据的第一对应关系，利用第一对应关系，得到监测模型。

监测模型创建单元，还可以具体用于对历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障与历史监测数据的第二对应关系，利用第二对应关系，得到监测模型。

本发明实施例中，还包括：

接收模块，用于接收用户输入的过滤列表；

过滤模块，用于停止对过滤列表中记录的故障告警。

告警分析模块12，用于利用历史告警信息，分析出高频告警列表；

高频数据获取模块11，用于按照预设频率获取与高频告警列表中记录的故障相应的目标监测数据。

上述告警分析模块12，具体可以包括分析单元和创建单元；其中，

分析单元，用于利用历史告警信息的告警次数、告警位置和告警时间，分析出高频告警信息；

创建单元，用于接收用户输入的确定信息，并利用高频告警信息，得到高频告警列表。

可见，本发明实施例中通过获取监测对象的监测数据，利用历史监测数据，得到故障发生概率与历史监测数据的对应关系，利用对应关系并基于Spark框架制作而成的监测模型对监测数据进行分析，得到分析结果，再判断分析结果是否满足预设条件，决定是否告警，如果满足预设条件，则告警，综上所述，实现了主动告警，即，在故障发生前，依据当前数据分析出可能发生的故障并提前告警，从而提醒用户进行维护和关注，避免了故障的发生或扩大。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种监测告警方法及***进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种监测告警方法，其特征在于，包括：

获取监测数据；

利用监测模型分析所述监测数据，得到分析结果；

判断所述分析结果是否满足预设条件；

如果满足，则进行告警；

其中，所述监测模型为基于Spark框架，利用历史监测数据，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

2.根据权利要求1所述的监测告警方法，其特征在于，所述监测数据包括监测日志和运维人员的操作日志。

3.根据权利要求1所述的监测告警方法，其特征在于，所述监测模型创建过程，包括：

对所述历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

4.根据权利要求1至3任一项所述的监测告警方法，其特征在于，所述监测模型训练过程，还包括：

对所述历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障与所述历史监测数据的第二对应关系，利用所述第二对应关系，得到所述监测模型。

5.根据权利要求1至3任一项所述的监测告警方法，其特征在于，还包括：

接收用户输入的过滤列表；

停止对所述过滤列表中记录的故障告警。

6.根据权利要求1至3任一项所述的监测告警方法，其特征在于，还包括：

利用历史告警信息，分析出高频告警列表；

按照预设频率获取与所述高频告警列表中记录的故障相应的目标监测数据。

7.根据权利要求4所述的监测告警方法，其特征在于，所述利用历史告警信息，分析出高频告警列表的过程，包括：

利用所述历史告警信息的告警次数、告警位置和告警时间，分析出高频告警信息；

接收用户输入的确定信息，并利用所述高频告警信息，得到所述高频告警列表。

8.一种监测告警***，其特征在于，包括：

获取模块，用于获取监测数据；

分析模块，用于利用监测模型分析所述监测数据，得到分析结果；

判断模块，用于判断所述分析结果是否满足预设条件；

告警模块，用于如果满足，则进行告警；

其中，所述监测模型为基于Spark框架，利用历史监测数据，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

9.根据权利要求8所述的监测告警***，其特征在于，所述分析模块，包括：

监测模型创建单元，用于对所述历史监测数据逐条进行SQL统计分析，并将具有联系的数据建立关联，得到故障发生概率与所述历史监测数据的第一对应关系，利用所述第一对应关系，得到所述监测模型。

10.根据权利要求8所述的监测告警***，其特征在于，还包括：

告警分析模块，用于利用历史告警信息，分析出高频告警列表；

高频数据获取模块，用于按照预设频率获取与所述高频告警列表中记录的故障相应的目标监测数据。