CN114595126A - 一种基于规则引擎的告警方法、系统、存储设备及终端 - Google Patents

Abstract

本发明提供的一种基于规则引擎的告警方法、系统、存储设备及终端，所述方法包括：采集多个设备的实时数据，并将实时数据发送到Kafka中；设置每个设备的告警规则并进行配置形成相应设备的规则数据，并将规则数据发送到Kafka中；以及将全部规则数据存储至元数据库中；数据流引擎Flink从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；数据流引擎Flink将告警消息发送到Kafka中；告警存储和消息推送引擎从Kafka中订阅告警消息；按照已配置的消息推送策略，推送给用户；本发明具有数据处理效率较高的有益效果，适用于监控告警领域。

Description

一种基于规则引擎的告警方法、系统、存储设备及终端

技术领域

本发明涉及监控告警的技术领域，具体涉及一种基于规则引擎的告警方法、系统、存储设备及终端。

背景技术

当前市面上的电力监控告警系统，多以设置阈值对比判断是否告警，因电力数据瞬时波动频繁，这种判断方式容易触发大量越限告警；因此，单纯依赖瞬时越限，难以判断设备是否真正存在故障，告警功能的有效性极低。

此外，设置阈值的告警方式导致系统中积累数万甚至数十万的告警数据，需要依靠人为经验进行甄别，不仅告警有效性依赖于人员素质，且极大降低运维人员工作效率。

发明内容

针对相关技术中存在的不足，本发明所要解决的技术问题在于：提供一种数据处理效率较高的基于规则引擎的告警方法、系统、存储设备及终端。

为解决上述技术问题，本发明采用的技术方案为：

一种基于规则引擎的告警方法，包括如下步骤：

S10，采集多个设备的实时数据，并将实时数据发送到Kafka中；

S20，设置每个设备的告警规则并进行配置形成相应设备的规则数据，并将规则数据发送到Kafka中；以及将全部规则数据存储至元数据库中；

其中，所述设备的规则数据包括：形成设备告警消息的规则条件、收敛条件和复归条件；

所述的规则条件包括：告警类型，与告警类型对应的至少一个告警级别，以及与每个告警级别对应的触发条件；

所述的收敛条件包括：为不同告警类型、不同告警级别的告警消息分别设置相应的告警推送频次；

所述的复归条件包括：在告警触发后的设定时间段内未再次触发告警后，将该告警标记为复归状态；

S30，数据流引擎Flink从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

S40，数据流引擎Flink将告警消息发送到Kafka中；

S50，告警存储和消息推送引擎从Kafka中订阅告警消息；

S60，按照已配置的消息推送策略，推送给用户。

优选地，还包括：存储订阅的告警消息至MongoDB中，以使用户进行查询、分析和挖掘。

优选地，所述步骤S30，具体包括：

S301，规则引擎将规则数据的字符内容动态加载为Drools规则处理器，并缓存至缓存系统库中；

S302，实时数据流入时，将不同设备的实时数据匹配至相应的规则处理器，对数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

S303，自动记录告警消息的行为事件明细，并入库。

优选地，所述步骤S30，根据触发条件、收敛条件生成告警消息，具体包括：

判断是否满足触发条件，如满足，则生成预告警；

根据生成的预告警，判断是否满足收敛条件，如满足，则不发出告警消息，不满足，则生成告警消息；

或根据生成的预告警，在设定时间内，判断是否再次生成预告警，如生成，则，不生成，则，判定该预告警为临时告警，将其标记为复归状态。

优选地，所述的告警规则，包括：基础规则、由基础规则形成的规则组、以及收敛规则；

所述的基础规则包括：

事实：表示被判断的主体和属性；

条件：表示判断的逻辑，包括：大于、小于、等于、大于等于、小于等于、连续上升、连续下降；

阈值：表示判断的依据；

统计规则：表示计数、求和、最大值、最小值、平均；

时间要素：涉及的时间范围、时长；

告警级别：表示告警的重要程度；

告警类型：表示告警的主体内容；

所述的规则组由一个或多个基础规则组成；

所述的收敛规则包括：收敛时间和收敛时长。。

相应地，还包括：一种基于规则引擎的告警系统，包括：

数据采集模块，用于采集多个设备的实时数据，并将实时数据发送到Kafka中；

规则配置模块，用于设置每个设备的告警规则并进行配置形成相应设备的规则数据，并将规则数据发送到Kafka中；以及将全部规则数据存储至元数据库中；其中，所述设备的规则数据包括：形成设备告警消息的规则条件、收敛条件和复归条件；

所述的规则条件包括：告警类型，与告警类型对应的至少一个告警级别，以及与每个告警级别对应的触发条件；所述的收敛条件包括：为不同告警类型、不同告警级别的告警消息分别设置相应的告警推送频次；所述的复归条件包括：在告警触发后的设定时间段内未再次触发告警后，将该告警标记为复归状态；

匹配模块，用于从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

告警模块，用于将告警消息发送到Kafka中，以及从Kafka中订阅告警消息，按照已配置的消息推送策略，推送给用户。

优选地，还包括：存储模块，用于存储订阅的告警消息，以使用户进行查询、分析和挖掘。

优选地，所述匹配模块包括：

加载模块，用于将规则数据的字符内容动态加载为Drools规则处理器，并缓存至缓存系统库中；

处理模块，用于当实时数据流入时，将不同设备的实时数据匹配至相应的规则处理器，对数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

记录模块，用于自动记录告警消息的行为事件明细，并入库。

相应地，还包括：存储设备，其中存储有多条指令，其特征在于：所述指令适于由处理器加载并执行如上所述的一种基于规则引擎的告警方法。

相应地，还包括：终端，：包括：

处理器，适于实现各指令；以及

存储设备，适于存储多条指令，所述指令适于由处理器加载并执行如上所述的一种基于规则引擎的告警方法。

本发明的有益技术效果在于：

1、本发明中，通过设置每个设备的告警规则并进行配置形成相应设备的规则数据，使得规则数据的设置可根据不同类型企业及用户需求进行呈现多样化的趋势，并通过引入数据流引擎Fl ink从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，进而将告警消息发送到Kafka中，以及通过告警存储和消息推送引擎从Kafka中订阅告警消息；实现将业务从应用数据中分离，大大提升数据处理的灵活性和处理效率，实用性极强。

2、本发明中，针对不同级别、类型的告警可分别设置推送频次，对大量的告警信息进行了层次性区分，压缩了消息量，提高了信息精度。

附图说明

图1是本发明实施例一提供的一种基于规则引擎的告警方法的流程示意图；

图2是本发明实施例一提供的一种基于规则引擎的告警系统的结构示意图；

图3是本发明实施例二提供的一种基于规则引擎的告警方法中步骤S30的流程示意图；

图4是本发明实施例二提供的一种基于规则引擎的告警系统的结构示意图；

图5为本发明通过软件实现时的系统流程图；

图中：10为数据采集模块，20为规则配置模块，30为匹配模块，40为告警模块，50为存储模块；

301为加载模块，302为处理模块，303为记录模块。

具体实施方式

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

其次，本发明结合示意图进行详细描述，在详述本发明实施例时，为便于说明，表示器件结构的剖面图会不依一般比例作局部放大，而且所述示意图只是示例，其在此不应限制本发明保护的范围。此外，在实际制作中应包含长度、宽度及深度的三维空间尺寸。

本发明中，Kafka是指分布式发布-订阅消息系统，是一个分布式的，可划分的，冗余备份的持久性的日志服务，它主要用于处理活跃的流式数据。

以下结合附图详细说明本发明的一个实施例。

实施例一

图1是本发明实施例一提供的一种基于规则引擎的告警方法的流程示意图；如图1所示，一种基于规则引擎的告警方法，包括如下步骤：

S10，采集多个设备的实时数据，并将实时数据发送到Kafka中；

S20，设置每个设备的告警规则并进行配置形成相应设备的规则数据，并将规则数据发送到Kafka中；以及将全部规则数据存储至元数据库中；

其中，所述设备的规则数据包括：形成设备告警消息的规则条件、收敛条件和复归条件；

所述的规则条件包括：告警类型，与告警类型对应的至少一个告警级别，以及与每个告警级别对应的触发条件；

所述的收敛条件包括：为不同告警类型、不同告警级别的告警消息分别设置相应的告警推送频次；

所述的复归条件包括：在告警触发后的设定时间段内未再次触发告警后，将该告警标记为复归状态；

S30，数据流引擎Flink从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

S40，数据流引擎Flink将告警消息发送到Kafka中；

S50，告警存储和消息推送引擎从Kafka中订阅告警消息；

S60，按照已配置的消息推送策略，推送给用户。

具体地，所述步骤S30，根据触发条件、收敛条件生成告警消息，具体包括：

判断是否满足触发条件，如满足，则生成预告警；

根据生成的预告警，判断是否满足收敛条件，如满足，则不发出告警消息，不满足，则生成告警消息；

或根据生成的预告警，在设定时间内，判断是否再次生成预告警，如生成，则，不生成，则，判定该预告警为临时告警，将其标记为复归状态。

本实施例中，在发出告警消息后，为降低重复告警的频率；用户可配置收敛条件：使得在告警消息发生之后的一段时间内发生多个重复告警时，可自定义控制推送告警消息的频率，即在告警消息的基础上，对告警消息的推送做了进一步的收敛。

本实施例中，还包括：存储订阅的告警消息至MongoDB中，以使用户进行查询、分析和挖掘。

具体地，步骤S60，按照已配置的消息推送策略，推送给用户，具体包括：在系统级别的告警筛选基础上，可进行多级消息类型创建、企业层消息接收过滤、用户层消息推送配置；

如：告警消息配置进行分层设置：第一层该企业是否需要接收告警；第二层，如果该企业需要接收告警那么推送给哪些用户，第三层进行用户配置。

进一步地，还可包括：回路告警配置；所述的回路告警配置的具体实现可为：设置系统策略库和用户策略库，对于策略库中告警策略，在回路上可以一键勾选配置；如：可通过字典表配置告警级别(一般、重要、紧急)与告警类型。

本实施例中，字典表也就是数据字典，用于一些特定的数据的规范化处理。这些数据除了通过专门的维护入口对它进行维护以外其他用户不允许操作。

一般地，本实施例中的告警类型可包含：过压、欠压、超温等，通常，一个告警类型可以配置不同的告警等级；如：

告警类型：过压，告警级别：一般，触发条件：电压超过额定电压的5％；

告警类型：过压，告警级别：重要，触发条件：电压超过额定电压的10％。

进一步地，在同一时间，可能会生成多条告警，级别最高的是主告警，之后，将生成的告警进行下一阶段的判断，判断是否满足收敛条件，如：收敛条件是20分钟，则在20分钟内相同的告警不再通知用户。

更进一步地，触发报警后，如果在设定的时间内未再次触发，则认为该告警为临时告警，可能由于瞬时波动产生，认为其恢复到了正常状态，可将其标记为复归状态。

图2是本发明实施例一提供的一种基于规则引擎的告警系统的结构示意图；如图2所示，一种基于规则引擎的告警系统，包括：

数据采集模块10，用于采集多个设备的实时数据，并将实时数据发送到Kafka中；

规则配置模块20，用于设置每个设备的告警规则并进行配置形成相应设备的规则数据，并将规则数据发送到Kafka中；以及将全部规则数据存储至元数据库中；其中，所述设备的规则数据包括：形成设备告警消息的规则条件、收敛条件和复归条件；

所述的规则条件包括：告警类型，与告警类型对应的至少一个告警级别，以及与每个告警级别对应的触发条件；所述的收敛条件包括：为不同告警类型、不同告警级别的告警消息分别设置相应的告警推送频次；所述的复归条件包括：在告警触发后的设定时间段内未再次触发告警后，将该告警标记为复归状态；

匹配模块30，用于从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

告警模块40，用于将告警消息发送到Kafka中，以及从Kafka中订阅告警消息，按照已配置的消息推送策略，推送给用户；

存储模块50，用于存储订阅的告警消息，以使用户进行查询、分析和挖掘。

本实施例一提供的一种基于规则引擎的告警方法及系统，通过设置每个设备的告警规则并进行配置形成相应设备的规则数据，使得规则数据的设置可根据不同类型企业及用户需求进行呈现多样化的趋势，并通过引入数据流引擎Fl ink从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，进而将告警消息发送到Kafka中，以及通过告警存储和消息推送引擎从Kafka中订阅告警消息；实现将业务从应用数据中分离，大大提升数据处理的灵活性和处理效率，最终实现按照已配置的消息推送策略，推送给用户；实用性极强。

此外，本实施例中，针对不同级别、类型的告警可分别设置推送频次，对大量的告警信息进行了层次性区分，压缩了消息量，提高了信息精度。

实施例二

图3是本发明实施例二提供的一种基于规则引擎的告警方法中步骤S30的流程示意图；如图3所示，在实施例一的基础上，一种基于规则引擎的告警方法，所述步骤S30，具体包括：

S301，规则引擎将规则数据的字符内容动态加载为Drools规则处理器，并缓存至缓存系统库中；

S302，实时数据流入时，将不同设备的实时数据匹配至相应的规则处理器，对数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

S303，自动记录告警消息的行为事件明细，并入库。

具体地，Drools是一款开源规则引擎，可以将复杂且多变的业务规则从硬编码中解放出来，以规则脚本的形式存放在文件或特定的存储介质中(例如存放在数据库中)，使得业务规则的变更不需要修改项目代码、重启服务器就可以在线上环境立即生效是使用时，可通过预定义的Drools模板，根据规则的具体内容，生成规则文件，规则引擎就会动态加载规则内容。

进一步地，每个设备均可具有独立的规则，步骤S302中，可使每个设备对应一个规则处理器，以提高数据处理效率。

本实施例中，所述的告警规则，包括：基础规则、由基础规则形成的规则组、以及收敛规则；

所述的基础规则包括：

事实：表示被判断的主体和属性；

条件：表示判断的逻辑，包括：大于、小于、等于、大于等于、小于等于、连续上升、连续下降；

阈值：表示判断的依据；

统计规则：表示计数、求和、最大值、最小值、平均；

时间要素：涉及的时间范围、时长；

告警级别：表示告警的重要程度；

告警类型：表示告警的主体内容；

所述的规则组由一个或多个基础规则组成；

所述的收敛规则包括：收敛时间和收敛时长。

图4是本发明实施例二提供的一种基于规则引擎的告警系统的结构示意图；如图4所示，一种基于规则引擎的告警系统，所述匹配模块30包括：

加载模块301，用于将规则数据的字符内容动态加载为Drools规则处理器，并缓存至缓存系统库中；

处理模块302，用于当实时数据流入时，将不同设备的实时数据匹配至相应的规则处理器，对数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

记录模块303，用于自动记录告警消息的行为事件明细，并入库。

图5为本发明通过软件实现时的系统流程图；通过该流程图，对告警过程的数据流向做了说明。

此外，本实施例以一个具体的告警规则为例进行说明：

(1)数据采集模块

每分钟采集一次实时数据，Ua，Ub，Uc等数据均会上传；

(2)规则配置模块

告警类型：过压告警；触发条件：Ua>246且Ub>246且Uc>246：

告警等级：紧急；

收敛条件：在5分钟之内触发5次；

(3)匹配模块的加载模块：

告警规则配置完成后，动态生成Drools规则文件，并加载为规则处理器；

(4)匹配模块的处理模块：

接收设备实时数据(该设备的电压等)，根据设备找到匹配的规则处理器，并计算实时数据，是否满足告警的条件，若满足告警的条件则生成预告警。

(如果该规则触发内容需要持续5分钟以上，则需判断当前时间5分钟之内的数据是否都满足)。

(5)匹配模块的处理模块：根据生成的预告警，结合收敛条件，判断是否生成告警。

(如收敛条件为20分钟，若20分钟内已经产生过告警，则不生成，否则生成告警)。

本发明还提供了存储设备，其中存储有多条指令，所述指令适于由处理器加载并执行如上所述的一种基于规则引擎的告警方法。

所述存储设备可为一计算机可读存储介质，可以包括：ROM、RAM、磁盘或光盘等。

本发明还提供了终端，包括：

处理器，适于实现各指令；以及

存储设备，适于存储多条指令，所述指令适于由处理器加载并执行如权利要求1至5任一所述的一种基于规则引擎的告警方法。

所述终端可为任意能够实现物品防伪溯源的装置，该装置可以是各种终端设备，例如：台式电脑、手提电脑等，具体可以通过软件和/或硬件来实现。

综上，本发明提供的一种基于规则引擎的告警方法、系统、存储设备及终端，通过告警规则进行告警设置，能够将告警策略应用到回路中，实现对应回路采集到数据的实时处理过滤，监测到触发该告警规则后，可根据收敛条件和推送配置进行相应的告警推送，极大的提高了监控告警的数据处理效率，实用性极强。

在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

在本发明中，除非另有明确的规定和限定，第一特征在第二特征“上”或“下”可以是第一和第二特征直接接触，或第一和第二特征通过中间媒介间接接触。而且，第一特征在第二特征“之上”、“上方”和“上面”可是第一特征在第二特征正上方或斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”可以是第一特征在第二特征正下方或斜下方，或仅仅表示第一特征水平高度小于第二特征。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法、装置及系统中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所述领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其他设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本发明也不针对任何特定的编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在本申请所提供的实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (10)

1.一种基于规则引擎的告警方法，其特征在于：包括如下步骤：

S10，采集多个设备的实时数据，并将实时数据发送到Kafka中；

S20，设置每个设备的告警规则并进行配置形成相应设备的规则数据，并将规则数据发送到Kafka中；以及将全部规则数据存储至元数据库中；

其中，所述设备的规则数据包括：形成设备告警消息的规则条件、收敛条件和复归条件；

所述的规则条件包括：告警类型，与告警类型对应的至少一个告警级别，以及与每个告警级别对应的触发条件；

所述的收敛条件包括：为不同告警类型、不同告警级别的告警消息分别设置相应的告警推送频次；

所述的复归条件包括：在告警触发后的设定时间段内未再次触发告警后，将该告警标记为复归状态；

S30，数据流引擎Flink从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

S40，数据流引擎Flink将告警消息发送到Kafka中；

S50，告警存储和消息推送引擎从Kafka中订阅告警消息；

S60，按照已配置的消息推送策略，推送给用户。

2.根据权利要求1所述的一种基于规则引擎的告警方法，其特征在于：还包括：存储订阅的告警消息至MongoDB中，以使用户进行查询、分析和挖掘。

3.根据权利要求1所述的一种基于规则引擎的告警方法，其特征在于：所述步骤S30，具体包括：

S301，规则引擎将规则数据的字符内容动态加载为Drools规则处理器，并缓存至缓存系统库中；

S302，实时数据流入时，将不同设备的实时数据匹配至相应的规则处理器，对数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

S303，自动记录告警消息的行为事件明细，并入库。

4.根据权利要求1所述的一种基于规则引擎的告警方法，其特征在于：所述步骤S30，根据触发条件、收敛条件生成告警消息，具体包括：

判断是否满足触发条件，如满足，则生成预告警；

根据生成的预告警，判断是否满足收敛条件，如满足，则不发出告警消息，不满足，则生成告警消息；

或根据生成的预告警，在设定时间内，判断是否再次生成预告警，如生成，则，不生成，则，判定该预告警为临时告警，将其标记为复归状态。

5.根据权利要求1所述的一种基于规则引擎的告警方法，其特征在于：所述的告警规则，包括：基础规则、由基础规则形成的规则组、以及收敛规则；

所述的基础规则包括：

事实：表示被判断的主体和属性；

条件：表示判断的逻辑，包括：大于、小于、等于、大于等于、小于等于、连续上升、连续下降；

阈值：表示判断的依据；

统计规则：表示计数、求和、最大值、最小值、平均；

时间要素：涉及的时间范围、时长；

告警级别：表示告警的重要程度；

告警类型：表示告警的主体内容；

所述的规则组由一个或多个基础规则组成；

所述的收敛规则包括：收敛时间和收敛时长。

6.一种基于规则引擎的告警系统，其特征在于：包括：

数据采集模块(10)，用于采集多个设备的实时数据，并将实时数据发送到Kafka中；

规则配置模块(20)，用于设置每个设备的告警规则并进行配置形成相应设备的规则数据，并将规则数据发送到Kafka中；以及将全部规则数据存储至元数据库中；其中，所述设备的规则数据包括：形成设备告警消息的规则条件、收敛条件和复归条件；

所述的规则条件包括：告警类型，与告警类型对应的至少一个告警级别，以及与每个告警级别对应的触发条件；所述的收敛条件包括：为不同告警类型、不同告警级别的告警消息分别设置相应的告警推送频次；所述的复归条件包括：在告警触发后的设定时间段内未再次触发告警后，将该告警标记为复归状态；

匹配模块(30)，用于从Kafka中订阅实时数据与规则数据，对实时数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

告警模块(40)，用于将告警消息发送到Kafka中，以及从Kafka中订阅告警消息，按照已配置的消息推送策略，推送给用户。

7.根据权利要求6所述的一种基于规则引擎的告警系统，其特征在于：还包括：

存储模块(50)，用于存储订阅的告警消息，以使用户进行查询、分析和挖掘。

8.根据权利要求6所述的一种基于规则引擎的告警系统，其特征在于：所述匹配模块(30)包括：

加载模块(301)，用于将规则数据的字符内容动态加载为Drools规则处理器，并缓存至缓存系统库中；

处理模块(302)，用于当实时数据流入时，将不同设备的实时数据匹配至相应的规则处理器，对数据进行规则匹配，根据触发条件、收敛条件、复归条件，发出/不发出告警消息；

记录模块(303)，用于自动记录告警消息的行为事件明细，并入库。

9.存储设备，其中存储有多条指令，其特征在于：所述指令适于由处理器加载并执行如权利要求1至5任一所述的一种基于规则引擎的告警方法。

10.终端，其特征在于：包括：

处理器，适于实现各指令；以及

存储设备，适于存储多条指令，所述指令适于由处理器加载并执行如权利要求1至5任一所述的一种基于规则引擎的告警方法。

Images