CN102034148A - 一种监控系统的事件预警及防风暴策略的实现方法 - Google Patents

Abstract

本发明提供一种监控系统的事件预警及防风暴策略的实现方法，通过制定一套服务策略来实现最终事件的权重分级和采用告警合并以及监控策略规则来防止风暴的产生，包括以下内容：1)由数据采集器对于具体指标的数据进行采集；2)采集之后的数据经过服务策略分析形成不同级别的告警事件；3)为了保证告警事件不进行重复产生，在缓存中进行了告警合并处理；4)告警合并处理之后的告警信息再进一步经过健康策略分析之后形成最终需要的事件，发送到事件流程进行处理。

Description

一种监控系统的事件预警及防风暴策略的实现方法

技术领域

本发明涉及IT服务管理领域，通过ITIL最佳实践库实现工具和流程的有效结合，是一种监控系统的事件预警及防风暴策略的实现方法。

背景技术

ITIL(Information Technology Infrastructure Library)：即信息技术基础构架库，一套被广泛承认的用于有效IT服务管理的实践准则；它以流程为导向、以客户为中心，通过整合IT服务与企业业务，提高企业的IT服务提供和服务支持的能力和水平；通过ITIL理论基础构建的IT管理系统，由组织、流程、数据和工具四个有机组成部分组成了一个完整的系统；流程是指对于特定事件有一定的处理流程，如事件管理；工具主要是一些协助实现IT系统管理的软件，利用这些软件能够实现一些管理工作的自动化，减少人力；流程和工具的合理使用决定了IT服务管理是否能够实现预期的目标；本发明是描述监控系统工具和事件流程之间存在的一些问题的解决方法，事件管理是ITIL流程当中的一个重要流程，如果IT基础设施的事件都由人工去录入那将是一个非常耗尽人力的事情；可行的方法就是引入监控系统，由监控系统来监控企业IT基础设施的运行状况，在出现问题的时候自动产生事件发送给事件流程来处理，但是监控系统往往都是只负责发送问题，对于问题的数量、质量、必要性都没有一个评判标准，这就导致了相同的问题不停的产生，所有的都进入事件的流程管理那将大大降低工具所提供的好处，这个在IT管理领域称为“事件风暴”，如何有效的防止“事件风暴”的发生是本发明要解决的问题。

ITIL已经成为IT服务行业的标准，它所提出来的流程为导向，整合IT服务于企业业务，提高企业的IT服务提供和服务支持的能力和水平，越来越被大公司所认同，流程化消减企业管理费用的开支，提高管理的有效性；如果实现自动化IT管理流程，那必将提高IT的生产效率，提高管理的有效性。但是自动化工具的使用未必能实现预期的效果，往往会面临很多问题；事件流程在IT服务管理当中作为主要流程，如果实现事件管理的自动化那将给生产效率带来很大提升，但往往一些监控工具的使用为了实现自动化，却往往带来更严重的结果造成事件风暴的形成，本发明实现从指标数据采集到事件的生成，中间经过很多防风暴策略的处理。

发明内容

本发明的目的是提供一种监控系统的事件预警及防风暴策略的实现方法。

本发明的目的是按以下方式实现的，通过制定一套服务策略来实现最终事件的权重分级和采用告警合并以及监控策略规则来防止风暴的产生，包括以下内容：

1)由数据采集器对于具体指标的数据进行采集；

2)采集之后的数据经过服务策略分析形成不同级别的告警事件；

3)为了保证告警事件不进行重复产生，在缓存中进行了告警合并处理；

4)告警合并处理之后的告警信息再进一步经过健康策略分析之后形成最终需要的事件，发送到事件流程进行处理；

指标根据定义的采集指标内容进行采集，针对日常运维管理中主要关注的基础设施运行状况信息进行设定，保证采集数据的有效性；采集过来的数据经过服务策略分析，在这里定义了相关的服务策略，设定了不同程度的阈值权值；通过阈值分析之后的指标真正决定是否产生告警，如果认为属于告警范围将进行告警的合并处理，主要看当前指标是否一直处于告警状态，相同的指标如果一直在持续将认为是同一次告警；健康策略分析是对告警进行相应的规则处理，处理之后的告警才会真正形成一条事件，这条事件最终会跟事件流程对接；

具体实现内容如下：

指标数据采集

指标是通过采集器进行采集的，作为企业IT环境基础设施的原始数据，这些基础设施的稳定运行将是企业日常生产运行的最根本保障；指标的设定往往是根据服务管理的好坏来设定，对于日常运维管理比较常用的指标进行采集，采集的指标要保证实效性；

服务策略分析

通过采集器采集的指标是比较原始的信息，我们要对每个指标产生的告警级别进行划分并设定权重值，设定紧急度、影响度；不同的紧急度和影响度将提示管理人员采取不同的轻重缓急措施；

告警合并处理

如果故障长时间未解决，可能会引起告警风暴，大量同类的告警数据充斥屏幕让人不厌其烦，给查看和分析其他告警增加了难度，要预防告警风暴，可以通过在告警中设置计数器和状态字段，把同类的告警划为一个，计数器增加同时改变状态，这样既不影响其他告警的展现，又能看到告警发生的次数，现在是根据条件表中的紧急度影响度与优先级作为一个判断依据，来区分同一个指标的告警是否可以归结为同一个告警，避免同样的告警多次出现；

处理办法：使用一个容器作为告警的缓存，把生成的告警根据指标与优先级等作为主键添加到缓存中，在把对象添加到缓存中的同时，会赋一个时间戳的值，后面可以通过这个时间戳判断缓存中的告警是否已经超时；

对新生成的告警，根据指标名称与优先级等组合键在缓存中查找是否有同类告警，然后依据查找的结果做出不同的操作；

1)找到同优先级告警：更新原告警的状态为持续，计数器加一；

2)找到低优先级告警：更新原告警的状态为升级，计数器加一；

3)找到高优先级告警：更新原告警的状态为关闭；

4)插入新的告警：把原告警从缓存中删除，把新告警添加到缓存中；

5)未找到目标告警：插入新的告警，把告警添加到缓存中；

通过上述步骤处理后，把重复出现的同一类告警合并为同一个告警，进而有效的避免了告警风暴的产生；

健康策略分析

经过上述一系列处理，认为还不能为最终进入管理流程的事件，要形成时间还需要经过一套规则引擎处理，下面制定几种规则分别是：

1)逻辑型规则：用于判断多个事件以何种条件发生将意味着故障的发生；

2)算术型规则：用于判断多个事件的值满足何种算数条件意味着故障发生，这种判断规则对于业务稽核非常重要，因为电信行业中，业务规则的稽核，往往意味着许多数值之间遵循特定的配平关系；

3)次数型规则：用于判断事件是否频繁发生达到特定的次数；

4)时间型规则：用于判断事件是否发生在特定的时间段，或者事件持续告警超过特定的时长；

事件关联分析/业务稽核引擎识别以上规则的任意组合，同时，还允许在已经定义的故障的基础上，定义告警之间的多种关联规则。

本发明的有益效果是：

1)本发明实现了通过定义指标的经验阈值，通过经验阈值进行判断事件产生的预警级别，数据采集器对指标需要的数据采集之后通过之前的定义进行算法判断，从而形成不同告警的服务策略；

2)本发明通过告警的合并比对分析以及相应的健康策略分析防止最终事件的风暴产生。

具体实施方式

本发明实现过程如下，指标根据我们定义的采集指标内容进行采集，针对我们日常运维管理中主要关注的基础设施运行状况信息进行设定，保证采集数据的有效性；采集过来的数据经过服务策略分析，在这里定义了相关的服务策略，设定了不同程度的阈值权值；通过阈值分析之后的指标真正决定是否产生告警，如果认为属于告警范围将进行告警的合并处理，主要看当前指标是否一直处于告警状态，相同的指标如果一直在持续将认为是同一次告警；健康策略分析是对告警进行相应的规则处理，处理之后的告警才会真正形成一条事件，这条事件最终会跟事件流程对接。

具体实现内容如下：

指标数据采集

指标是通过采集器进行采集的，作为企业IT环境基础设施的原始数据，这些基础设施的稳定运行将是企业日常生产运行的最根本保障；指标的设定往往是根据服务管理的好坏来设定，对于日常运维管理比较常用的指标进行采集。采集的指标要保证实效性。

服务策略分析

通过采集器采集的指标是比较原始的信息，我们要对每个指标产生的告警级别进行划分并设定权重值，设定紧急度、影响度；不同的紧急度和影响度将提示管理人员采取不同的轻重缓急措施。

下表优先级不能由用户选择，而是根据紧急度和影响度加权生成。

告警合并处理

如果故障长时间未解决，可能会引起告警风暴，大量同类的告警数据充斥屏幕让人不厌其烦，给查看和分析其他告警增加了难度。要预防告警风暴，可以通过在告警中设置计数器和状态字段，把同类的告警划为一个，计数器增加同时改变状态，这样既不影响其他告警的展现，又能看到告警发生的次数。现在是根据条件表中的紧急度影响度与优先级作为一个判断依据，来区分同一个指标的告警是否可以归结为同一个告警，避免同样的告警多次出现。

处理办法：使用一个容器作为告警的缓存，把生成的告警根据指标与优先级等作为主键添加到缓存中。在把对象添加到缓存中的同时，会赋一个时间戳的值，后面可以通过这个时间戳判断缓存中的告警是否已经超时。

对新生成的告警，根据指标名称与优先级等组合键在缓存中查找是否有同类告警，然后依据查找的结果做出不同的操作。

1)找到同优先级告警：更新原告警的状态为持续，计数器加一；

2)找到低优先级告警：更新原告警的状态为升级，计数器加一；

3)找到高优先级告警：更新原告警的状态为关闭；

4)插入新的告警：把原告警从缓存中删除，把新告警添加到缓存中；

5)未找到目标告警：插入新的告警，把告警添加到缓存中；

通过上面的步骤处理后，就可以把重复出现的同一类告警合并为同一个告警，进而有效的避免了告警风暴的产生。

健康策略分析

经过上面的一系列处理，我们认为还不能为最终进入管理流程的事件，要形成时间还需要经过一套规则引擎处理，下面制定了几种规则分别是：

1)逻辑型规则：

用于判断多个事件以何种条件发生将意味着故障的发生，如：

A and B，代表A和B事件必须同时发生则判断为故障。

A or B，代表A或者B任意一个发生即为故障。

2)算术型规则：

用于判断多个事件的值满足何种算数条件意味着故障发生，这种判断规则对于业务稽核非常重要，因为电信行业中，业务规则的稽核，往往意味着许多数值之间遵循特定的配平关系。如：

A+B＜100，代表事件A的值和B的值之和如果小于100，则认为故障发生。

A+B！＝C，代表事件A和B的值之和如果不等于C的值，则认为故障发生。

3)次数型规则：

用于判断事件是否频繁发生达到特定的次数。在实际使用环境中，某种事件发生一次，一般不是什么大问题，比如，偶然发生的CPU利用率过高的告警，并不会对业务系统造成影响，但如果在短时间内CPU利用率频繁告警，则可能意味着较严重的问题。

4)时间型规则：

用于判断事件是否发生在特定的时间段，或者事件持续告警超过特定的时长。

事件关联分析/业务稽核引擎可以识别以上规则的任意组合，同时，还允许在已经定义的故障的基础上，定义告警之间的多种关联规则。

同时，规则引擎提供可扩充的内置函数支持，进一步增强告警能力，如下表：

Claims (1)

1.一种监控系统的事件预警及防风暴策略的实现方法，其特征在于，通过制定一套服务策略来实现最终事件的权重分级和采用告警合并以及监控策略规则来防止风暴的产生，包括以下内容：

1)由数据采集器对于具体指标的数据进行采集；

2)采集之后的数据经过服务策略分析形成不同级别的告警事件；

3)为了保证告警事件不进行重复产生，在缓存中进行了告警合并处理；

4)告警合并处理之后的告警信息再进一步经过健康策略分析之后形成最终需要的事件，发送到事件流程进行处理；

指标根据定义的采集指标内容进行采集，针对日常运维管理中主要关注的基础设施运行状况信息进行设定，保证采集数据的有效性；采集过来的数据经过服务策略分析，在这里定义了相关的服务策略，设定了不同程度的阈值权值；通过阈值分析之后的指标真正决定是否产生告警，如果认为属于告警范围将进行告警的合并处理，主要看当前指标是否一直处于告警状态，相同的指标如果一直在持续将认为是同一次告警；健康策略分析是对告警进行相应的规则处理，处理之后的告警才会真正形成一条事件，这条事件最终会跟事件流程对接；

具体实现内容如下：

指标数据采集

指标是通过采集器进行采集的，作为企业IT环境基础设施的原始数据，这些基础设施的稳定运行将是企业日常生产运行的最根本保障；指标的设定往往是根据服务管理的好坏来设定，对于日常运维管理比较常用的指标进行采集，采集的指标要保证实效性；

服务策略分析

通过采集器采集的指标是比较原始的信息，我们要对每个指标产生的告警级别进行划分并设定权重值，设定紧急度、影响度；不同的紧急度和影响度将提示管理人员采取不同的轻重缓急措施；

告警合并处理

如果故障长时间未解决，可能会引起告警风暴，大量同类的告警数据充斥屏幕让人不厌其烦，给查看和分析其他告警增加了难度，要预防告警风暴，可以通过在告警中设置计数器和状态字段，把同类的告警划为一个，计数器增加同时改变状态，这样既不影响其他告警的展现，又能看到告警发生的次数，现在是根据条件表中的紧急度影响度与优先级作为一个判断依据，来区分同一个指标的告警是否可以归结为同一个告警，避免同样的告警多次出现；

处理办法：使用一个容器作为告警的缓存，把生成的告警根据指标与优先级等作为主键添加到缓存中，在把对象添加到缓存中的同时，会赋一个时间戳的值，后面可以通过这个时间戳判断缓存中的告警是否已经超时；

对新生成的告警，根据指标名称与优先级等组合键在缓存中查找是否有同类告警，然后依据查找的结果做出不同的操作；

1)找到同优先级告警：更新原告警的状态为持续，计数器加一；

2)找到低优先级告警：更新原告警的状态为升级，计数器加一；

3)找到高优先级告警：更新原告警的状态为关闭；

4)插入新的告警：把原告警从缓存中删除，把新告警添加到缓存中；

5)未找到目标告警：插入新的告警，把告警添加到缓存中；

通过上述步骤处理后，把重复出现的同一类告警合并为同一个告警，进而有效的避免了告警风暴的产生；

健康策略分析

经过上述一系列处理，认为还不能为最终进入管理流程的事件，要形成时间还需要经过一套规则引擎处理，下面制定几种规则分别是：

1)逻辑型规则：用于判断多个事件以何种条件发生将意味着故障的发生；

2)算术型规则：用于判断多个事件的值满足何种算数条件意味着故障发生，这种判断规则对于业务稽核非常重要，因为电信行业中，业务规则的稽核，往往意味着许多数值之间遵循特定的配平关系；

3)次数型规则：用于判断事件是否频繁发生达到特定的次数；

4)时间型规则：用于判断事件是否发生在特定的时间段，或者事件持续告警超过特定的时长；

事件关联分析/业务稽核引擎识别以上规则的任意组合，同时，还允许在已经定义的故障的基础上，定义告警之间的多种关联规则。