CN101540698B

CN101540698B - 一种事件处理系统和方法

Info

Publication number: CN101540698B
Application number: CN2009100834286A
Authority: CN
Inventors: 王利彬
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2009-05-04
Filing date: 2009-05-04
Publication date: 2011-09-07
Anticipated expiration: 2029-05-04
Also published as: CN101540698A

Abstract

本发明实施例提供了一种事件处理系统和方法，其中，该系统包括：事件管理子系统和事件分析插件；所述事件管理子系统包含与事件分析插件对应的事件管理槽；用于接收事件源发送的事件，并通过所述事件管理槽触发所述事件分析插件；所述事件分析插件用于接收所述触发，将所述事件的格式转换为预设定的事件格式，并通过所述事件管理子系统提供转换后的事件。采用本发明，能够降低系统升级成本，提高系统的稳定性。

Description

一种事件处理系统和方法

技术领域

本发明涉及网络管理技术，特别是涉及一种事件处理系统和方法。

背景技术

目前，在网络管理技术中，事件处理系统统一处理事件源发送的事件，其中，事件源包含一个或多个不同的厂商。由于事件源不同，事件承载协议也会相应不同，比如，厂商A发送的事件所承载的协议为SAMP协议；而厂商B发送的事件所承载的协议为SIP协议。为了保证事件处理系统能够识别出各个厂商发送的事件，现有方法是由各个厂商的软件负责将要发送给事件管理系统的事件进行格式化转换，其中，转换后的格式为事件处理系统可以识别的格式；之后，将格式转换后的事件发送给事件处理系统。

参见图1，图1为现有的事件处理流程图。如图1所示，该流程可包括以下步骤：

步骤101，摄像头检测出异常事件，并将检测出的异常事件发送给编码器。

这里，异常事件具体为一些容易导致故障或非法活动的事件。比如，摄像头在夜晚检测到某个办公室有非法移动事件，该非法移动事件有可能意味着偷盗行为发生，因此，摄像头将检测出的异常事件发送给编码器。

步骤102，编码器将异常事件的格式编码成事件处理系统能够识别的格式，并将编码后的事件发送给事件处理系统。

步骤103，事件处理系统对事件进行解析，得到事件所涉及到的区域信息和事件信息。

通常，事件中包含了该事件所发生的时间信息、该事件所涉及到的区域信息等；因此，事件处理系统可以直接从接收的事件中提取出该事件所涉及到的区域信息和事件信息。

步骤104，事件处理系统通过短消息方式将得到的区域信息和事件信息发送给安防人员。

如此，安防人员接收到区域信息和事件信息后，直接到达该区域察看。可见，现有方法能够使得安防人员不必24小时紧盯监控屏幕，大大提高了工作效率。

但是，现有提供的方法中，各个厂商需要自身将事件格式统一转换为事件处理系统识别的格式，这样，就会使得每一个厂商必须有一套格式转换的软件系统，其中，不同厂商的软件系统需要额外的运行于特定的硬件平台之上，如此，就会占用大量的硬件资源。并且，由于不同的厂商具有自身对应的一套格式转换的软件系统，如此，当整个系统升级时，还需要对该软件系统进行升级，导致升级成本高，稳定性差。

发明内容

有鉴于此，本发明提供了一种事件处理系统和方法，以便于降低系统升级成本，提高系统的稳定性。

本发明的技术方案是这样实现的：

一种事件处理系统，包括：事件管理子系统和事件分析插件；

所述事件管理子系统包含与事件分析插件对应的事件管理槽；用于接收事件源发送的事件，并通过所述事件管理槽触发所述事件分析插件；

所述事件分析插件用于接收所述触发，将所述事件的格式转换为预设定的事件格式，并通过所述事件管理子系统提供转换后的事件。

一种事件处理方法，该方法应用于包括事件管理子系统和用于对事件进行格式化处理的事件分析插件的事件处理系统中；其中，所述事件管理子系统包含与事件分析插件对应的事件管理槽；该方法包括：

步骤A，事件管理子系统接收事件源发送的事件，并通过自身包含的事件管理槽触发所述事件分析插件；

步骤B，所述事件分析插件用于接收所述触发，将步骤A中接收的事件的格式转换为预设定的事件格式，并通过所述事件管理子系统提供转换后的事件。

由上可述，本发明实施例提供的事件处理系统和方法，其中，该系统包括：事件管理子系统和事件分析插件；事件管理子系统包含与事件分析插件对应的事件管理槽；用于接收事件源发送的事件，并通过所述事件管理槽触发所述事件分析插件；所述事件分析插件用于接收所述触发，将所述事件的格式转换为预设定的事件格式，并通过所述事件管理子系统提供转换后的事件。如此，事件处理系统利用设置在自身中的插件实现所有外部不同厂商比如事件源发送的事件的格式转换，这样，就无需现有技术中需要分别为各个外部事件源(厂商或系统)设置对应的格式转换软件系统，从而在系统进行升级时，避免了为各个不同厂商中的软件系统升级，只需更新事件处理系统中的插件即可，而由于插件比较灵活，相比于现有的软件系统，其在系统升级比如增加插件或者卸载插件时，不需要对整个系统重新编译和连接，如此，降低系统升级成本，提高系统的稳定性。

进一步地，本发明中由于在事件处理系统中设置对不同厂商发送的事件进行格式转换的插件，这样，该插件只需运行在事件处理系统提供的硬件平台上，其中，该插件可与系统中的主程序共享硬件资源，如此，不会占用各个厂商的硬件资源，也大大节省了各个厂商的硬件资源。

附图说明

图1为现有的事件处理流程图；

图2为本发明实施例提供的事件处理系统基本结构图；

图3为本发明实施例提供的事件处理系统详细结构图；

图4为本发明实施例提供的事件处理方法基本流程图；

图5为本发明实施例提供的事件处理方法详细流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图及具体实施例对本发明作进一步地详细描述。

参见图2，图2为本发明实施例提供的事件处理系统基本结构图。如图2所示，该系统可包括：事件管理子系统201和事件分析插件202。

其中，事件管理子系统201包含与事件分析插件202对应的事件管理槽，用于接收事件源发送的事件，并通过所述事件管理槽触发事件分析插件202。其中，事件源为外部厂商设备或者系统设备，其在检测到异常情况时发送该异常对应的事件。比如，编码器在检测到温度感应器中的温度超过预设阈值时，发送温度过高的事件信息给事件管理子系统201，如此，事件源为编码器。其中，事件源发送的事件包含了该事件中的参数信息、该事件的事件类型信息等。

这里，事件管理槽具体应用为：周期或者按照用户设定的时间检测其对应的事件分析插件，在监测到后，加载该事件分析插件；当需要触发事件分析插件时，调用对应的事件分析插件。需要说明的是，本实施例中事件管理子系统201还包括其他功能单元，比如用于提供查询的事件列表单元等，该其他功能单元所执行的操作与现有技术类似，因此，本实施例不再赘述。

具体地，事件管理子系统201先确定当前接收的事件的类型，之后，通过自身包含的事件管理槽触发(或调用)该确定的类型对应的事件分析插件来对该当前接收的事件进行分析。

事件分析插件202用于接收事件管理子系统201的触发，将事件管理子系统201接收的事件的格式转换为预设定的事件格式，并通过事件管理子系统201提供转换后的事件。其中，事件分析插件的个数可以为一个以上。并且，每一个事件分析插件中包含的其能够分析出的事件类型可以为一种，也可以为多种，本实施例并不具体限定。

这里，预设定的事件格式具体可有多种形式，优选地，本实施例中可将第一字段表示所述事件的类型、第二字段表示事件源的地址、第三字段表示事件源的地址类型、第四字段表示事件源发送事件的绝对时间信息、第五字段表示事件包含的变量个数以及第6字段至第N字段表示事件包含的变量列表，并且，变量之间可用预先设置的符号比如逗号“，”隔开。其中，N为正整数，其取值与事件包含的变量的个数有关。当然，上述格式只是一种举例，并非限定本发明实施例的应用。

这里，事件分析插件202之所以能将事件的格式转换为预设定的格式，主要是由于事件分析插件202按照预设定的事件接收规范接口设计的。其中，该事件接收规范接口用于表示将事件的格式转换为预设定的格式的操作。

优选地，本实施例中事件分析插件201还可进一步根据预设定的插件启动接口规范和插件关闭接口规范设计。其中，插件启动接口规范用于表示事件分析插件的初始化操作，其中，该初始化操作具体可包括为事件分析插件分配全局缓存；插件关闭接口规范用于表示在卸载或退出事件分析插件时释放该事件分析插件，具体地，如果初始化操作包括为该事件分析插件分配全局缓存；则释放该事件分析插件为：释放该事件分析插件对应的全局缓存空间的操作。

需要说明的是，本实施例中事件源发送的事件具体可包括：事件名称(其中，事件名称全局唯一)、该事件包含的参数信息(具体为参数的名称、参数的类型等，本实施例并不具体限定)等。优选地，当需要在事件分析插件增加某一种类型的事件时，可按照预先设定的规范格式在事件分析插件201中增加该事件信息，其中，该预先设定的规范格式具体可为XML或者动态加载库(DLL)、或者为XML和DLL的组合。下述以XML和DLL的组合来描述如何增加事件：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--事件定义-->

<！--事件1，name：事件名，用于区别其他事件，全局唯一-->

<！--所在的动态库名-->

<dllLib>sample_event.dll</dllLib>

<！-事件包含的参数描述-->

<param>

<！--参数1的名字-->

<！--参数1的描述-->

<！--参数1的类型，INT/BIGINT/CHAR/ENUM-->

</param>

<param>

<！--参数2的名字-->

<！--参数2的描述-->

<！--参数2的类型，INT/BIGINT/CHAR/ENUM-->

</param>

</params>

</event>

<！--事件2-->

……

<！--事件N-->

</events>

如此，实现了本发明实施例提供的事件处理系统的基本结构框架。

下面结合具体实施例对本发明实施例提供的事件处理系统的详细结构图进行描述。

参见图3，图3为本发明实施例提供的事件处理系统的详细结构图。如图3所示，该系统包括：事件管理子系统301、事件分析插件302、告警规则管理子系统303和告警规则插件304。

其中，事件管理子系统301包含与事件分析插件302对应的事件管理槽，具体功能与图2所示的事件管理子系统201的功能类似，这里不再赘述。

事件分析插件302的具体功能与图2所示的事件分析插件202的具体功能类似，这里不再赘述。

告警规则管理子系统303包含与告警规则插件304对应的告警规则管理槽，用于接收事件管理子系统301提供的事件；并通过告警规则管理槽触发告警规则插件304。

这里，告警规则管理槽具体应用为：周期或者按照用户设定的时间检测其对应的告警规则插件，在监测到后，加载该告警规则插件；当需要触发告警规则插件时，调用对应的告警规则插件。

这里，告警规则管理子系统303还包含除告警规则管理槽之外的其他功能单元，但是，该其他功能单元所执行的操作与现有技术类似，这里不再赘述。

告警规则插件304用于接收告警规则管理子系统303的触发，判断告警规则管理子系统303接收的事件是否满足预设定的告警规则，如果是，将该事件升级为告警事件，并通过告警规则管理子系统303提供该告警事件。其中，告警规则插件304的个数可以为一个以上，本实施例并不具体限定。

这里，预设定的告警规则在实现时具体有多种实现形式，比如可以为预设的事件参数、事件源、事件类型和时间范围的任意一种组合。本实施例并不具体限定。

比如，若预设定的告警规则为预设的事件参数，则判断告警规则管理子系统303接收的事件是否满足预设定的告警规则具体为：判断告警规则管理子系统303接收的事件所包含的事件参数是否为预设的事件参数，如果是，则确定满足预设定的告警规则；否则，确定不满足预设定的告警规则。

需要说明的是，为便于区分升级后的各个告警事件，告警规则中还可包含定义告警事件的名字、以及有多个事件时，各个事件升级时对应的逻辑关系(其中，该逻辑关系包括“和”、“或”等)等，本实施例并不具体限定。

本实施例中告警规则插件304可按照预先设定的告警规则规范设计。其中，预先设定的告警规则规范具体可为告警规则的描述格式，本实施例中可利用XML文件格式描述告警规则，下述以XML文件格式描述各个告警规则，具体为：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--告警规则集合-->

<alarm_rules>

<！--告警规则1-->

<alarm_rule name＝″alarm_rule1″>

<！--升级后的告警事件的名字，实质是一种新事件-->

<alarm_name>alarm_name</alarm_name>

<！--事件升级的逻辑关系，与(AND)或者或(OR)关系，与表示事件同

时发生，或表示任一事件发生-->

<event_logic>OR</event_logic>

<！--产生逻辑关系事件发生的时间范围，单位秒-->

<！--转换后的告警源，可以是系统内任何设备，此处用系统可

唯一标识设备的ID来识别-->

<alarm_source>SOURCE DEVICE ID</alarm_source>

<！--触发告警的事件列表-->

<event_combination>

<！--事件源信息-->

<event_source>SOURE IP</event_source>

<！--事件参数-->

<event_paras>

<event_para name＝″para1″>para1_value</event_para>

<event_para name＝″para2″>para2_value</event_para>

……

<event_para name＝″paraN″>paraN_value</event_para>

</event_paras>

</event>

……

</event_combination>

</alarm_rule>

<！--告警规则2-->

<alarm_rule name＝″alarm rule2″>......</alarm_rule>

……

<！--告警规则N-->

<alarm_rule name＝″alarm_ruleN″>......</alarm_rule>

</alarm_rules>

优选地，如图3所示，该系统还可包括：布防策略管理子系统305和布防策略插件306。

其中，布防策略管理子系统305包含与布防策略插件306对应的布防策略管理槽，用于在告警规则插件304的判断结果为是时，通过该布防策略管理槽触发布防策略插件306。

这里，布防策略管理槽具体应用为：周期或者按照用户设定的时间检测其对应的布防策略插件，在监测到后，加载该布防策略插件；当需要触发布防策略插件时，调用对应的布防策略插件。

这里，布防策略管理子系统305还可包含除布防策略管理槽之外的其他功能单元，但是由于该其他功能单元与现有技术类似，这里不再赘述。

布防策略插件306用于接收布防策略管理子系统305的触发，提供预设的布防阶段的告警生效时间信息。其中，该预设的布防阶段的告警生效时间信息具体可为一个时间点，也可为一个时间段，本实施例并不具体限定。需要说明的是，布防策略插件306的个数可以为一个以上，本实施例并不具体限定。

具体地，本实施例中布防策略插件306可按照预设的布防信息规范设计；这里，预设的布防信息规范具体为布防信息的描述格式，优选地，本实施例采用XML文件格式描述布防信息比如预设的布防阶段的告警生效时间信息。以布防策略插件306提供的布防信息为预设的布防阶段的告警生效时间段为例，则布防策略插件306采用XML文件格式描述预设的布防阶段的告警生效时间段具体为：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--布防策略集合-->

<deploy_policys>

<！--布防策略1-->

<deploy_policy name＝″deploy_policy1″>

<！--布防策略生效的起始时间，格式：year-month-day-->

<sart_time>2008-4-15</start_time>

<！--布防策略生效的终止时间，格式：year-month-day-->

<end_time>2009-4-15</end_time>

<！--具体时间段类型，月(month)，周(week)，日(day)-->

<detail_time_type>day</detail_time_type>

<！--具体时间段列表，对于月，周，日，含义分别为当月的第几天，周的第几天，当天的第多少秒(用HH:MM格式)，用“，”分隔起止时间-->

<detail_time_list>

</detail_time_list>

<！--布防阶段的告警规则-->

<deploying_alarm_rules>

<alarm_rule>alarm_rule1</alarm_rule>

<alarm_rule>alarm_rule2</alarm_rule>

……

<alarm_rule>alarm_ruleN</alarm_rule>

</deploying_alarm_rules>

<！--布防策略2-->

<deploy_policy name＝″deploy_policy2″>......</deploy_policy>

……

<！--布防策略N-->

<deploy_policy name＝″deploy_policyN″>......</deploy_policy>

</deploy_policys>

优选地，为便于用户获知撤防阶段的告警终止时间，布防策略插件306还可提供预设的撤防阶段的告警终止时间信息。因此，上述只是一种举例，并不用于限定本发明实施例的应用。

告警规则插件304根据预设的布防阶段的告警生效时间信息判断当前是否需要将该事件升级为告警事件，如果是，则将该事件升级为告警事件。具体地，如果预设的布防阶段的告警生效时间信息为时间点，则告警规则插件304判断当前时间点是否为预设的布防阶段的告警生效时间点，如果是，确定当前需要将该事件升级为告警事件；否则，确定当前不需要将该事件升级为告警事件。当然，如果预设的布防阶段的告警生效时间信息为时间段，则告警规则插件304判断当前时间是否在预设的布防阶段的告警生效时间段之内，如果是，确定当前需要将该事件升级为告警事件；否则，确定当前不需要将该事件升级为告警事件。

需要说明的是，上述以布防策略插件306针对所有事件提供一个统一的预设的布防阶段的告警生效时间信息为例。本实施例中布防策略插件306还可根据不同的事件提供不同的预设的布防阶段的告警生效时间信息，如此，告警规则插件304需要确定当前事件对应的预设的布防阶段的告警生效时间信息；之后，根据该确定的预设的布防阶段的告警生效时间信息判断当前是否需要将该事件升级为告警事件，如果是，则将该事件升级为告警事件。

优选地，如图3所示，该系统还可包括：告警管理子系统307和告警管理插件308。

其中，告警管理子系统307包含与告警管理插件308对应的告警管理槽；用于接收告警规则管理子系统303提供的告警事件，通过所述告警管理槽触发告警管理插件308。这里，告警管理槽具体应用为：周期或者按照用户设定的时间检测其对应的告警管理插件，在监测到后，加载该告警管理插件；当需要触发告警管理插件时，调用对应的告警管理插件。

这里，告警管理子系统307还可包含除告警管理槽之外的其他功能单元，但是，该其他功能单元与现有技术类似，这里不再赘述。

告警管理插件308用于接收告警管理子系统307的触发，将告警事件的格式转换为预设定的告警格式，并通过告警管理子系统307提供转换后的告警事件。其中，告警管理插件308的个数可以为一个以上。

这里，预设定的告警格式具体可与事件分析插件302转换的预设定的事件格式类似，这里不再赘述。

优选地，告警规则插件304将事件升级为告警事件的操作进一步包括确定所述告警事件对应的实际告警源信息，将确定出的实际告警源信息携带在告警事件中。这里，实际告警源为实际告警对应的设备，比如，编码器检测到温度感应器中的温度超过预设阈值时，发送温度过高的事件信息给事件管理子系统301，则告警规则插件304可确定出实际告警源信息为温度感应器，而非事件源编码器。

如此，告警管理子系统307提供的转换后的告警事件中携带了告警规则插件304确定的实际告警源信息。

如图3所示，该系统还可包括：联动策略管理子系统309和联动策略插件310。

其中，联动策略管理子系统309包含与联动策略插件310对应的联动策略管理槽，用于接收携带了实际告警源信息的告警事件，通过所述联动策略管理槽触发联动策略插件310。这里，联动策略管理槽具体应用为：周期或者按照用户设定的时间检测其对应的联动策略插件，在监测到后，加载该联动策略插件；当需要触发联动策略插件时，调用对应的联动策略插件。

这里，联动策略管理子系统309还可包含除联动策略管理槽之外的其他功能单元，但是，该其他功能单元与现有技术类似，这里不再赘述。

联动策略插件310用于接收联动策略管理子系统309的触发，根据预设定的告警事件、告警源和关联动作的对应关系确定联动策略管理子系统301接收的携带了实际告警源信息的告警事件对应的关联动作，根据联动策略管理子系统309接收的告警事件，触发该确定出的关联动作。其中，联动策略插件310的个数为一个以上，本实施例可根据实际情况设置，这里不作限定。

这里，预设定的告警事件、告警源和关联动作的对应关系具体可简称为联动策略，其中，联动策略插件310可根据联动策略的描述规范设计，优选地，本实施例中可采用XML文件格式描述联动策略，具体如下：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--联动策略集合-->

<relevant_policys>

<！--联动策略1-->

<relevant_policy name＝″relevant_policy1″>

<！--告警事件-->

<alarm_name>alarm_name</alarm_name>

<！--告警源-->

<alarm_source>SOURCE DEVICE ID</alarm_source>

<！--告警参数匹配规则，所有参数都匹配或者匹配任一参数，

与(OR)或者或(AND)-->

<alarm_para_logic>OR</alarm_para_logic>

<！--告警匹配参数列表-->

<alarm_paras>

<alarm_para name＝″para1″>para1_value</alarm_para>

<alarm_para name＝″para2″>para2_value</alarm_para>

……

<alarm_para name＝″paraN″>paraN_value</alarm_para>

</alarm_paras>

<！--触发的动作列表-->

<action_combination>

<！--多个动作的执行顺序，并行(parallel)或者串行(serial)

-->

<exec_order>serial</exec_order>

<！-执行的动作1-->

<！--动作执行前的延迟时间，单位：秒-->

<delay_time>3</delay_time>

<action_paras>

<！--动作参数可以来自告警(ALARM)，或者直

接填入(VALUE)，或者系统变量(SYSTEM)-->

<action_para name＝″para1″，type＝″ALARM″>

alarm_para_name</action_para>

<action_para name＝″para2″，type＝″VALUE″>

para2_value</action_para>

……

<action_para name＝″paraN″，type＝″SYSTEM″>

SYS_TIME</action_para>

</action_paras>

</action>

……

</action_combination>

</relevant_policy>

<！--联动策略2-->

<relevant_policy name＝″relevant_policy2″>......</relevant_policy>

……

<！--联动策略N-->

<relevant_policy name＝″relevant_policyN″>......</relevant_policy>

</relevant_policys>

如图3所示，该系统还可包括动作管理子系统311和动作管理插件312。

其中，动作管理子系统311包含与动作管理插件312对应的动作管理槽，用于通过所述动作管理槽触发动作管理插件312。这里，动作管理槽具体应用为：周期或者按照用户设定的时间检测其对应的动作管理插件，在监测到后，加载该动作管理插件；当需要触发动作管理插件时，调用对应的动作管理插件。

这里，动作管理子系统311还可包含除动作管理槽之外的其他功能单元，该其他功能单元与现有技术类似，这里不再赘述。

动作管理插件312用于接收动作管理子系统311的触发，并提供各个动作信息。其中，动作管理插件312的个数可以为一个以上，本实施例可根据实际情况设置，这里不作限定。

如此，联动策略插件310根据实际情况从动作管理插件312提供的动作信息中为各个的告警事件、告警源选择出对应的关联动作，如此，上述预设定的告警事件、告警源和关联动作的对应关系中的关联动作为动作管理插件312提供的动作中的一种或多种。

需要说明的是，动作管理插件312提供的动作信息具体可包含：动作名称和类型、动作所在的动态库名、动作对应的功能函数名、动作所需要的参数信息、以及各个参数信息的类型等，本发明实施例并不具体限定。应用中，动作管理插件312可根据预设定的动作信息描述规范设计，其中，预设定的动作信息描述规范具体可有多种实现形式，比如，采用采用XML文件格式或者DLL格式、或者XML文件格式和DLL格式的组合等。

下面以XML文件格式和DLL格式的组合描述动作信息为例，具体如下：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--动作集合-->

<！--动作1-->

<！--动作描述-->

<desc>Sample：发送E-mail</desc>

<！--动作所在的动态库名-->

<dllLib>sample_action.dll</dllLib>

<！--动作对应的功能函数名-->

<dllFuntion>sendMail</dllFuntion>

<！--动作所需要的参数描述-->

<param>

<！--参数1的名字-->

<name>toAddress</name>

<！--参数1的描述-->

<！--参数1的类型，INT/BIGINT/CHAR/ENUM-->

</param>

<param>

<！--参数2的名字-->

<name>subject</name>

<！--参数2的描述-->

<！--参数1的类型，INT/BIGINT/CHAR/ENUM-->

</param>

<param>

<！--参数3的名字-->

<name>content</name>

<！--参数3的描述-->

<！--参数3的类型，INT/BIGINT/CHAR/ENUM-->

</param>

</params>

</action>

<！--动作2-->

……

<！--动作N-->

</actions>

还需要说明的是，由于上述动作信息中包含了功能函数，本实施例可使用DLL机制为各个动作设计对应的功能函数，下面以windows系统下sample_action.dll的三个功能函数为例说明如何设计动作对应的功能函数的，具体如下：

//定义导出标记

#ifdef BUILD_PLUGIN_DLL

#define PLUGIN_EXPORT_declspec(dllexport)

#else

#define PLUGIN_EXPORT_declspec(dllimport)

#endif

//功能函数1，对应动作1

PLUGIN_EXPORT bool sendMail(char*toAddress，char*subject，char*content)；

//功能函数2，对应动作2

PLUGIN_EXPORT bool playAlarmSound()；

……

//功能函数N，对应动作N

PLUGIN_EXPORT bool snapPicture()；

如此，联动策略插件310根据上述联动策略确定联动策略管理子系统309接收的携带了实际告警源信息的告警事件对应的关联动作。

本实施例中，布防策略管理子系统305还用于在联动策略插件310确定出关联动作后，通过布防策略管理槽触发布防策略插件306。

布防策略插件306还用于提供预设的布防阶段的动作生效时间信息。其中，该预设的布防阶段的动作生效时间信息可以为时间点，也可以为时间段，本实施例并不具体限定。

其中，布防策略插件306可采用XML文件格式提供预设的布防阶段的动作生效时间信息，具体可与其提供预设的布防阶段的告警生效时间信息的方法类似，这里不再赘述。

优选地，为便于用户获知撤防阶段的动作终止时间，布防策略插件306还可提供预设的撤防阶段的动作终止时间信息。因此，上述只是一种举例，并不用于限定本发明实施例的应用。

联动策略插件310根据布防策略插件306提供预设的布防阶段的动作生效时间信息判断当前是否需要触发确定出的关联动作，如果是，触发该确定出的关联动作。

优选地，联动策略插件310触发所述确定出的关联动作的操作进一步包括：判断确定出的关联动作对应的模式为自动模式还是手工模式；如果是自动模式，自动触发确定出的关联动作；如果是手工模式，则不执行触发确定出的关联动作，而是增加联动策略管理子系统309接收的告警事件、该告警事件携带的实际告警源信息和确定出的关联动作三者之间的对应关系对应的执行标记，并提供所述执行标记给用户，其中，该执行标记主要是为了使用户知道联动策略管理子系统309接收的告警事件、该告警事件携带的实际告警源信息存在对应的关联动作；以便用户根据该执行标记选择是触发确定出的关联动作还是不触发确定出的关联动作。其中，关联动作对应的模式也可采用XML文件格式设置在联动策略插件310中。

上述本发明实施例提供的插件式的事件管理系统进行了描述，下面结合具体实施例对本发明实施例提供的方法进行描述。

参见图4，图4为本发明实施例提供的方法的基本流程图。该方法应用于事件处理系统中，其中，该事件处理系统包括事件管理子系统和用于对事件进行格式化处理的事件分析插件；事件管理子系统包含与事件分析插件对应的事件管理槽；如图4所示，该流程可包括以下步骤：

步骤401，事件管理子系统接收事件源发送的事件，并通过自身包含的事件管理槽触发事件分析插件。

步骤402，事件分析插件用于将步骤401中接收的事件的格式转换为预设定的事件格式，并通过事件管理子系统提供转换后的事件。

如此，实现了事件处理系统利用预先设置在自身中的插件实现外部事件源发送的事件的格式转换，这样，避免了现有技术中需要分别为各个外部事件源(厂商或系统)设置对应的格式转换软件系统，大大提高了事件处理的效率。由于插件比较灵活，相比于现有的软件系统，其在系统升级比如增加插件或者卸载插件时，不需要对整个系统重新编译和连接，如此，降低系统升级成本，提高系统的稳定性。

上述只是简单描述了本实施例提供的方法，下面结合具体实施例对本发明实施例提供的方法进行详细描述。

参见图5，图5为本实施例提供的事件处理方法详细流程图。如图5所示，该方法应用于事件处理系统，其中，本发明实施例中的事件处理流程中描述的操作可与图3所示的事件处理系统中的系统内部单元的具体操作过程一致。如图5所示，该流程可包括以下步骤：

步骤501，事件管理子系统接收事件源发送的事件，并通过自身包含的事件管理槽触发事件分析插件。

步骤502，事件分析插件将步骤501中接收的事件的格式转换为预设定的事件格式，并通过事件管理子系统提供转换后的事件。

步骤503，告警规则管理子系统接收事件管理子系统提供的事件；并通过自身包含的告警规则管理槽触发告警规则插件。

步骤504，告警规则插件判断步骤503中接收的事件是否满足预设定的告警规则，如果是，执行步骤505；否则，结束流程。

步骤505，使布防策略管理子系统通过其包含布防策略管理槽的触发布防策略插件。

步骤506，布防策略插件在所述布防策略管理子系统的触发下，提供预设的布防阶段的告警生效时间信息。

步骤507，告警规则插件从预设的布防策略插件中获取该事件对应的预设的布防阶段的告警生效时间信息，根据获取的预设的布防阶段的告警生效时间信息判断当前是否需要将该事件升级为告警事件，如果是，执行步骤508，否则，结束流程。

步骤508，确定所述告警事件对应的实际告警源信息，将该事件升级为告警事件，将确定出的实际告警源信息携带在告警事件中，通过告警规则管理子系统提供该告警事件。

步骤509，告警管理子系统接收告警规则管理子系统提供的告警事件，通过自身包含的告警管理槽触发告警管理插件。

步骤510，告警管理插件将步骤509中接收的告警事件的格式转换为预设定的告警格式，得到转换后的告警事件。

这里，转换后的告警事件中携带了步骤508中确定的实际告警源信息。

优选地，本步骤中预设的告警模式可与步骤502中预设定的事件模式类似。

步骤511，联动策略管理子系统接收转换后的告警事件，通过自身的联动策略管理槽触发联动策略插件。

需要说明的是，步骤509和步骤510并非是必须的，本实施例中在步骤508之后，也可省略步骤509和步骤510，直接执行步骤511至步骤517。因此，本实施例只是一种举例，并非限定本发明实施例的应用。

步骤512，联动策略插件根据预设定的告警事件、告警源和关联动作的对应关系确定当前告警事件对应的关联动作。

这里，确定出的关联动作可有多种形式，比如可以为通过邮件提供告警事件；或者通过短信息提供告警事件，或者自动触发该确定出的关联动作等，本实施例并不具体限定。

需要说明的是，联动策略插件根据预设的动作管理插件提供的动作信息为各个告警事件、告警源确定对应的关联动作，其中，关联动作可以为动作管理插件提供的动作信息中的一种动作或者多种动作的组合。

步骤513，从布防策略插件提供的预设的布防阶段的动作生效时间信息中确定当前告警事件对应的布防阶段的动作生效时间信息。

步骤514，根据确定的布防阶段的动作生效时间信息判断当前是否需要触发步骤512中确定出的关联动作，如果是，执行步骤515；否则，结束流程。

需要说明的是，当步骤514的判断结果为否时，也可根据实际情况执行其他的处理，比如等待需要通过确定的关联动作提供告警事件的时间等，本实施例并不具体限定。

步骤515，判断确定出的关联动作对应的模式为自动模式还是手工模式；如果是自动模式，执行步骤516；如果是手工模式，执行步骤517。

步骤516，自动触发所述确定出的关联动作。

这里，若步骤512确定的关联动作为通过邮件提供告警事件，则本步骤516可自动通过邮件提供告警事件。

步骤517，增加当前告警事件、该告警事件包含的实际告警源信息和确定出的关联动作三者之间的对应关系对应的执行标记。

如此，用户可根据步骤517提供的执行标记选择是否需要通过确定的关联动作提供该告警事件。

由上可述，本发明实施例提供的事件处理系统和方法，其中，事件管理子系统包含与事件分析插件对应的事件管理槽；用于接收事件源发送的事件，并通过所述事件管理槽触发所述事件分析插件；所述事件分析插件用于接收所述触发，将所述事件的格式转换为预设定的事件格式，并通过所述事件管理子系统提供转换后的事件。如此，事件处理系统利用设置在自身中的插件实现外部事件源发送的事件的格式转换，这样，避免了现有技术中需要分别为各个外部事件源(厂商或系统)设置对应的格式转换软件系统，大大提高了事件处理的效率。由于插件比较灵活，相比于现有的软件系统，其在系统升级比如增加插件或者卸载插件时，不需要对整个系统重新编译和连接，如此，降低系统升级成本，提高系统的稳定性。

进一步地，本实施例并非直接将事件源确定为告警源，而是对事件进行分析，确定该事件对应的实际告警源，以便用户针对实际告警源信息进行相应的处理，大大提高事件的处理效率。

更进一步地，本实施例通过设定布防策略，能够便于用户根据实际情况在不同的时间段执行不同的操作，更加具有实用性。

总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种事件处理系统，其特征在于，该系统包括：事件管理子系统和事件分析插件；其中，

2.根据权利要求1所述的系统，其特征在于，所述系统还包括告警规则管理子系统和告警规则插件；其中，

所述告警规则管理子系统包含与所述告警规则插件对应的告警规则管理槽，用于接收所述事件管理子系统提供的事件；并通过所述告警规则管理槽触发所述告警规则插件；

所述告警规则插件用于接收所述告警规则管理子系统的触发，判断告警规则管理子系统接收的事件是否满足预设定的告警规则，如果是，将该事件升级为告警事件，并通过所述告警规则管理子系统提供该告警事件。

3.根据权利要求2所述的系统，其特征在于，所述系统还包括：布防策略管理子系统和布防策略插件；其中，

所述布防策略管理子系统包含与布防策略插件对应的布防策略管理槽，用于在所述告警规则插件的判断结果为是时，通过所述布防策略管理槽触发所述布防策略插件；

所述布防策略插件用于接收所述布防策略管理子系统的触发，提供预设的布防阶段的告警生效时间信息；

所述告警规则插件根据预设的布防阶段的告警生效时间信息判断当前是否需要将所述告警规则管理子系统接收的事件升级为告警事件，如果是，则将所述告警规则管理子系统接收的事件升级为告警事件；

和/或

所述系统还包括告警管理子系统和告警管理插件；其中，

所述告警管理子系统包含与告警管理插件对应的告警管理槽；用于接收所述告警规则管理子系统提供的告警事件，通过所述告警管理槽触发所述告警管理插件；

所述告警管理插件用于接收所述告警管理子系统的触发，将所述告警事件的格式转换为预设定的告警格式，并通过所述告警管理子系统提供转换后的告警事件。

4.根据权利要求3所述的系统，其特征在于，所述告警规则插件将事件升级为告警事件的操作进一步包括：确定所述告警事件对应的实际告警源信息，将确定出的实际告警源信息携带在告警事件中；

所述系统还包括：联动策略管理子系统和联动策略插件；其中，

所述联动策略管理子系统包含与所述联动策略插件对应的联动策略管理槽，用于接收所述携带了实际告警源信息的告警事件，通过所述联动策略管理槽触发所述联动策略插件；

所述联动策略插件用于接收所述联动策略管理子系统的触发，根据预设定的告警事件、告警源和关联动作的对应关系确定所述联动策略管理子系统接收的携带了实际告警源信息的告警事件对应的关联动作，触发所述确定出的关联动作。

5.根据权利要求4所述的系统，其特征在于，所述系统还包括动作管理子系统和动作管理插件；其中，

所述动作管理子系统包含与所述动作管理插件对应的动作管理槽，用于通过所述动作管理槽触发所述动作管理插件；

所述动作管理插件用于接收所述动作管理子系统的触发，并提供各个动作信息；

所述联动策略插件根据所述动作管理插件提供的动作信息设定告警事件、告警源和关联动作的对应关系。

6.根据权利要求4所述的系统，其特征在于，所述布防策略管理子系统还用于在所述联动策略插件确定出关联动作后，通过所述布防策略管理槽触发所述布防策略插件；

所述布防策略插件还用于提供预设的布防阶段的动作生效时间信息；

所述联动策略插件根据所述预设的布防阶段的动作生效时间信息判断当前是否需要触发所述确定出的关联动作，如果是，触发所述确定出的关联动作；

和/或

所述联动策略插件触发所述确定出的关联动作的操作进一步包括：判断所述确定出的关联动作对应的模式为自动模式还是手工模式；如果是自动模式，自动触发所述确定出的关联动作；如果是手工模式，则增加所述联动策略管理子系统接收的告警事件、该告警事件携带的实际告警源信息和确定出的关联动作三者之间的对应关系对应的执行标记，并提供所述执行标记。

7.一种事件处理方法，其特征在于，该方法应用于包括事件管理子系统和用于对事件进行格式化处理的事件分析插件的事件处理系统中；其中，所述事件管理子系统包含与事件分析插件对应的事件管理槽；该方法包括：

8.根据权利要求7所述的方法，其特征在于，所述事件处理系统还包括告警规则管理子系统和用于提供告警规则的告警规则插件；其中，所述告警规则管理子系统包含与所述告警规则插件对应的告警规则管理槽；该方法还包括：

步骤C，所述告警规则管理子系统接收所述事件管理子系统提供的事件；并通过自身包含的告警规则管理槽触发所述告警规则插件；

步骤D，所述告警规则插件接收所述告警规则管理子系统的触发，判断步骤C中接收的事件是否满足预设定的告警规则，如果是，将该事件升级为告警事件，并通过所述告警规则管理子系统提供该告警事件。

9.根据权利要求8所述的方法，其特征在于，所述事件处理系统还包括布防策略管理子系统和用于提供预设的布防阶段的告警生效时间信息的布防策略插件，其中，所述布防策略管理子系统包含与布防策略插件对应的布防策略管理槽；所述步骤D中将事件升级为告警事件的操作包括：

步骤D1，使所述布防策略管理子系统通过所述布防策略管理槽触发布防策略插件；

步骤D2，所述布防策略插件接收步骤D1中的触发，提供预设的布防阶段的告警生效时间信息；

步骤D3，所述告警规则插件从所述布防策略插件中获取所述告警规则管理子系统接收的事件对应的预设的布防阶段的告警生效时间信息，根据获取的预设的布防阶段的告警生效时间信息判断当前是否需要将所述告警规则管理子系统接收的事件升级为告警事件，如果是，则将所述告警规则管理子系统接收的事件升级为告警事件；

和/或

所述事件处理系统还包括告警管理子系统和用于提供告警事件格式化处理的告警管理插件，其中，所述告警管理子系统包含与告警管理插件对应的告警管理槽；在所述将事件升级为告警事件之后，该方法进一步包括：

步骤E，告警管理子系统接收所述告警规则管理子系统提供的告警事件，通过所述告警管理槽触发所述告警管理插件；

步骤F，所述告警管理插件将步骤E中接收的告警事件的格式转换为预设定的告警格式，并提供该转换后的告警事件。

10.根据权利要求9所述的方法，其特征在于，所述将事件升级为告警事件的操作进一步包括：确定所述告警事件对应的实际告警源信息，将确定出的实际告警源信息携带在告警事件中；

所述事件处理系统还包括用于提供各个动作信息的动作管理插件、包含与联动策略插件对应的联动策略管理槽的联动策略管理子系统和用于根据所述动作管理插件提供的动作信息确定预设定的告警事件、告警源和关联动作的对应关系，并在所述联动策略管理子系统触发下提供预设定的告警事件、告警源和关联动作的对应关系的联动策略插件；

所述布防策略插件还用于提供预设的布防阶段的动作生效时间信息；在将事件升级为告警事件之后，进一步包括：

步骤G，联动策略管理子系统接收所述携带了实际告警源信息的告警事件，通过自身包含的联动策略管理槽触发所述联动策略插件；

步骤H，所述联动策略插件根据预设定的告警事件、告警源和关联动作的对应关系确定所述步骤G中接收的携带了实际告警源信息的告警事件对应的关联动作，

步骤I，所述联动策略插件从所述布防策略插件提供的预设的布防阶段的动作生效时间信息中确定所述携带了实际告警源信息的告警事件对应的布防阶段的动作生效时间信息；根据确定的布防阶段的动作生效时间信息判断当前是否需要触发所述确定出的关联动作，如果是，触发所述确定出的关联动作；或者，从所述布防策略插件提供的预设的布防阶段的动作生效时间信息中确定所述携带了实际告警源信息的告警事件对应的布防阶段的动作生效时间信息；根据确定的布防阶段的动作生效时间信息判断当前是否需要触发所述确定出的关联动作，如果是，判断所述确定出的关联动作对应的模式为自动模式还是手工模式；如果是自动模式，自动触发所述确定出的关联动作；如果是手工模式，则增加所述携带了实际告警源信息的告警事件、实际告警源信息和确定出的关联动作三者之间的对应关系对应的执行标记，并提供所述执行标记。