基于复杂事件处理引擎的动力环境监控方法及系统与流程

本发明涉及数据中心的动力与环境监控领域，具体涉及一种基于复杂事件处理引擎的动力环境监控方法及系统。

背景技术：

现有数据中心动力环境监控系统中，普遍都采用“大容量硬盘+依赖关系型数据库”方案先对所监控设备的数据进行高频率、无差别、实体化硬盘存储，然后客户端采用http(https)轮询的方法，按预设时间间隔向服务端请求新数据，服务端响应请求、从数据库取出对应数据并完成分析计算，若数据发生更新则返回对应数据，最终完成客户端数据的更新。

在上述这种传统监控架构下，首先无法满足数据实时流入、实时分析、实时告警的需求；其次，由于http(https)轮询每次都需要重新建立tcp连接并占用服务端资源，且多客户端请求、高频率轮询会给监控系统带来非常大的性能压力，造成监控系统的数据有效性低下、数据传输延时、无法及时发现潜在的问题。此外，该架构要求用户在配置存储时必须考虑集群监控设备的高并发数据量和存储时间要求，以预留足够的硬盘容量及网络带宽，导致设备的投资金额较大。

然而在实际运维业务逻辑中，用户真正关心的核心对象主要包括以下几点：

(1)对变化趋势异常的数据进行实时预警；

(2)对异常突变数据进行实时告警；

(3)满足以上两点前提下尽可能节省投资。

显而易见，上述传统方案除在技术方案上简单、容易实现之外，在数据实时性、有效性和节省投资方面均不能与用户的核心需求达到很好的契合度。

技术实现要素：

针对现有技术中存在的缺陷，本发明的目的在于提供一种基于复杂事件处理引擎的动力环境监控方法，其能提高动力环境监控系统的实时性和效率，并降低用户的带宽、存储投资。

为达到以上目的，本发明采取的技术方案是：

一种基于复杂事件处理引擎的动力环境监控方法，该方法包括以下步骤：

客户端设置复杂事件过滤规则，并根据所述复杂事件过滤规则生成订阅消息，所述订阅消息包括复杂事件过滤规则，及复杂事件过滤规则中客户端订阅数据的数据类别；

服务端接收订阅消息并将所述订阅消息发送至采集端的采集端复杂事件处理引擎cep；

采集端根据所述数据类别，提供被监控设备对应类别的第一数据，采集端cep根据复杂事件过滤规则过滤所述第一数据，将过滤后的第一数据发布至服务端，由服务端推送至客户端。

在上述技术方案的基础上，所述复杂事件过滤规则包括事件存储规则和事件告警规则，所述事件存储规则用于决定是否对事件进行存储，所述事件告警规则用于决定是否对事件进行告警。

在上述技术方案的基础上，所述事件存储规则包括：

通过判断事件流间隔采样值的变化阈值是否超限、事件流采样时间是否超时或事件流的存储周期是否过长，来决定是否进行存储。

在上述技术方案的基础上，所述服务端通过websocket将过滤后的第一数据推送至对应的客户端。

在上述技术方案的基础上，利用采集端cep提供的时间窗口处理模式和监听器机制，获取过滤后的第一数据。

本发明的目的在于提供一种基于复杂事件处理引擎的动力环境监控系统，其能提高动力环境监控系统的实时性和效率，并降低用户的带宽、存储投资。

为达到以上目的，本发明采取的技术方案是：

一种基于复杂事件处理引擎的动力环境监控系统，包括客户端、服务端和采集端，所述采集端包括采集端cep，

所述客户端用于设置复杂事件过滤规则，并根据所述复杂事件过滤规则生成订阅消息，所述订阅消息包括复杂事件过滤规则，及复杂事件过滤规则中客户端订阅数据的数据类别；

所述服务端用于接收订阅消息并将所述订阅消息发送至所述采集端cep；

所述采集端根据所述数据类别，提供被监控设备对应类别的第一数据，利用采集端cep根据复杂事件过滤规则过滤所述第一数据，并将过滤后的第一数据发布至服务端，由服务端推送至客户端。

在上述技术方案的基础上，所述复杂事件过滤规则包括事件存储规则和事件告警规则，所述事件存储规则用于决定是否对事件进行存储，所述事件告警规则用于决定是否对事件进行告警。

在上述技术方案的基础上，所述事件存储规则包括：

通过判断事件流间隔采样值的变化阈值是否超限、事件流采样时间是否超时或事件流的存储周期是否过长，来决定是否进行存储。

在上述技术方案的基础上，所述服务端通过websocket将过滤后的第一数据推送至对应的客户端。

在上述技术方案的基础上，所述采集端利用采集端cep提供的时间窗口处理模式和监听器机制，获取过滤后的第一数据。

与现有技术相比，本发明的优点在于：

(1)本发明基于复杂事件处理引擎的动力环境监控方法，由于采集端采用了复杂事件处理引擎，所有实时数据和告警都根据预设复杂事件过滤规则在内存中进行分析、处理，不涉及数据库操作，极大提高了系统的实时性和效率。

(2)采集端与服务端之间采用基于“发布—订阅”机制的mqtt协议，使得采集端仅发布客户端订阅的、满足预设复杂事件过滤规则的有意义数据，极大地减少了数据量，且保留了关键数据点。使得在相同的数据存储要求下用户的带宽、存储投资大大降低。过滤后的优先数据集能极大地改善下游大数据分析和人工智能预测性服务的计算性能。

(3)服务端与客户端之间采用websocket协议，解决了传统web客户端通过http(https)被动式轮询给服务端带来的性能压力。

附图说明

图1为本发明实施例中基于复杂事件处理引擎的动力环境监控方法的流程图；

图2为本发明实施例中复杂事件处理引擎的时间窗口处理模式的示意图；

图3为本发明实施例中基于复杂事件处理引擎的动力环境监控系统的结构框图；

图4为本发明实施例中采集端cep的结构框图。

具体实施方式

以下结合附图及实施例对本发明作进一步详细说明。

参见图1所示，本发明实施例提供一种基于复杂事件处理引擎的动力环境监控方法，该方法包括以下步骤：

s1.客户端设置复杂事件过滤规则，并根据所述复杂事件过滤规则生成订阅消息，所述订阅消息包括复杂事件过滤规则，及复杂事件过滤规则中客户端订阅数据的数据类别；

s2.服务端接收订阅消息并将所述订阅消息发送至采集端的采集端复杂事件处理引擎cep；

s3.采集端根据所述数据类别，提供被监控设备对应类别的第一数据，采集端cep根据复杂事件过滤规则过滤所述第一数据，将过滤后的第一数据发布至服务端，由服务端推送至客户端。

本实施例中首先在服务端上采用了服务端复杂事件处理引擎(complexeventsprocessing，cep)，以提供供客户端设置复杂事件过滤规则的平台。

具体而言，由服务端cep提供epl(eventpatternlanguage)语句，来让客户端自定义复杂事件过滤规则以过滤、订阅感兴趣的事件。

本实施例中，所述复杂事件过滤规则包括事件存储规则和事件告警规则，所述事件存储规则用于决定是否对事件进行存储，所述事件告警规则用于决定是否对事件进行告警。

优选地，所述事件存储规则可以是：通过判断事件流间隔采样值的变化阈值是否超限、事件流采样时间是否超时或事件流的存储周期是否过长，来决定是否进行存储。上述3种规则采用“或”的逻辑关系。当流入采集端cep的事件流与上述规则中的任一种相匹配时，则被认为是关键数据，并被存储至数据库，否则则丢弃该数据。

对于事件告警规则，相比于传统方案，服务端cep能够对不同被监控设备间不同信号进行组合逻辑运算，并使用javascript的math.js库来编辑逻辑运算表达式，并利用采集端cep进行规则匹配查询。相比于传统方案提供的有限范围的告警规则(如阈值上限、下限、上下限)，本实施例利用复杂事件处理引擎提供了一套全开放、可自由编辑的告警逻辑。

作为一个较好的实施方式，客户端与服务端之间采用websocket协议进行数据、告警推送。客户端在身份验证成功后，会通过socket.io库与服务端建立websocket连接，当前页面的js脚本会根据客户端自定义的复杂事件过滤规则产生数据订阅，即生成订阅消息，根据订阅消息可以知悉客户端订阅数据的数据类别。

优选地，采集端cep提供的时间窗口处理模式和监听器机制，获取过滤后的第一数据。

具体而言，参见图2所示，本实施例采用采集端cep提供的时间窗口处理模式(允许抖动时间为3s)，将实时事件流序列按时间窗口进行切片统计、过滤、分析。

图2中，w1-w4：代表在t+x时刻实时发生的事件；t+x(t+3、t+5等)：代表t时刻过了x秒；条形框：代表允许抖动时间为3s的时间窗口，条形框的下端代表当前的时刻；条形框把w1圈住，表示w1事件处于时间窗口范围内，采集端cep会进行规则匹配、分析，w1在条形框之外，表示w1事件脱离了时间窗口范围，采集端cep不会进行规则匹配、分析。

当进入采集端cep的实时事件流序列进入窗口范围时，会触发调用采集端cep提供的监听器机制，将事件发送至newevents队列，并调用update方法同客户端设置的复杂事件过滤规则进行匹配，若匹配成功，生成新的实时事件流序列并执行实时事件流序列的输出操作。若匹配失败，则将事件发送至oldevents队列，不执行输出操作。当事件离开时间窗口后，则会被发送至oldevents队列，并结束规则匹配的过程。

综上所述，由于采集端采用了复杂事件处理引擎，所有实时数据和告警都根据预设复杂事件过滤规则在内存中进行分析、处理，不涉及数据库操作，极大提高了系统的实时性和效率。采集端与服务端之间采用基于“发布—订阅”机制的mqtt协议，使得采集端仅发布客户端订阅的、满足预设复杂事件过滤规则的有意义数据，极大地减少了数据量，且保留了关键数据点。使得在相同的数据存储要求下用户的带宽、存储投资大大降低。过滤后的优先数据集能极大地改善下游大数据分析和人工智能预测性服务的计算性能。此外，服务端与客户端之间采用websocket协议，解决了传统web客户端通过http(https)被动式轮询给服务端带来的性能压力。

参见图3所示，本发明实施例提供一种基于复杂事件处理引擎的动力环境监控系统，其包括客户端、服务端和采集端和数据库。服务端上设有监控服务器和服务端cep，采集端的数量可以根据需求设置多个，每个采集端均包括采集端cep和监控主机，每个监控主机上连接有多个被监控设备。服务端cep和采集端cep均与数据库相连。为配合cep对时间序列数据流的操作，本实施例采用mongodb文档型数据库，对过滤后的数据进行存储操作。

其中，所述客户端用于设置复杂事件过滤规则，并根据所述复杂事件过滤规则生成订阅消息，所述订阅消息包括复杂事件过滤规则，及复杂事件过滤规则中客户端订阅数据的数据类别。

所述服务端用于接收订阅消息并将所述订阅消息发送至所述采集端cep；

所述采集端根据所述数据类别，提供被监控设备对应类别的第一数据，利用采集端cep根据复杂事件过滤规则过滤所述第一数据，并将过滤后的第一数据发布至服务端，由服务端推送至客户端。

本实施例中的动力环境监控，指的是针对数据中心各类动力设备及环境变量进行集中统一的监控。因此，被监控设备可包括：ups(不间断电源)、交直流电源分配柜、暖通设备、视频门禁等各类安防设备、温湿度等各类环境传感器。

监控数据包括与监控主机所连接的所有监控设备的采样信号、事件告警、控制命令及端口状态所构成的数据集，系统通过对各个独立的监控设备对象进行遥测、遥信，为设备的日常监控及维护提供了集中统一的智能化管理运维平台。

被监控设备可通过物理串口/ai/di接口、协议转换器与监控主机连接，具体的，物理串口可包含rs232、rs422或rs485串口，ai接口可包含4～20ma或0～10v模拟信号接口，并由监控主机统一进行协议解析、协议转换。

本实施例中，服务端和采集端均采用轻量级开源的复杂事件处理引擎(服务端cep和采集端cep)来替代传统架构中的复杂关系处理工作，实现在内存中进行高效的实时事件流处理。其中采集端cep主要进行实时事件流序列规则匹配查询操作，服务端cep引擎则只是预留了对它的上一级管理系统具备数据筛选、过滤功能。

具体而言，在服务端cep上主要使用规则定义组件来作为客户端设置复杂事件过滤规则的平台，规则定义组件提供的epl(eventpatternlanguage)语句，相比于传统架构，可自定义特定的匹配规则以过滤、订阅感兴趣的事件，规则定义完成后将统一存入规则库。规则库负责存储已经定义好的复杂事件过滤规则，并注册到采集端cep。

本实施例中的复杂事件过滤规则包括事件存储规则和事件告警规则，客户端按照规则库定义组件提供的3种事件存储规则：事件流间隔采样值的变化阈值(绝对值、百分比)超限、事件流采样时间超时、自定义事件流的存储周期，按运维需求在客户端界面选择性定义事件流的变化存储阈值、存储周期及采样超时存储的时限，进行存储规则的定义目的是对大量处于正常范围且几乎无变化的数据起到过滤作用、对真正对用户有价值的关键数据起到筛选作用。

在客户端，用户可按照现场实际运维需求，新建或选择已有的告警事件，按顺序依次完成设备及信号的选择、组合、告警表达式编辑、各告警规则定义的工作，完成告警规则的定义后，客户端即按照用户设置的规则通过监控服务器来订阅监控主机的数据。

监控设备数据经由监控主机进行统一解析转化后，由监控主机内部的复杂事件处理引擎根据设置的规则对数据进行分析、处理。

参见图4所示，采集端cep包括输入适配器、复杂事件检测组件和输出适配器，整个采集端cep引擎处理流程均在内存中完成，保证了事件处理的高效性。

对于输入适配器，本实施例采用csv(commaseparatedvalues)输入适配器，将各被监控设备数据统一转换成复杂事件处理引擎可处理的java.util.map数据类型，以排除各被监控设备间的差异性。转换后的每个csv文件均包含一个时间戳列，复杂事件处理引擎通过计时器线程读取csv文件，然后将实时事件流序列传送给复杂事件检测组件。

复杂事件检测组件是采集端cep的核心模块，按照规则库中已经注册的规则，对输入适配器输入的实时事件流序列进行匹配查询操作。本实施例选择采用复杂事件处理引擎提供的时间窗口处理模式(3s)，将实时事件流序列按时间窗口进行切片统计、过滤、分析。当进入复杂事件处理引擎的实时事件流序列进入窗口范围时，会触发调用复杂事件处理引擎提供的监听器机制，将事件发送至newevents队列，并调用update方法同规则库中的规则进行匹配，若匹配成功，生成新的实时事件流序列并执行实时事件流序列的输出操作。若匹配失败，则将事件发送至oldevents队列，不执行输出操作。当事件离开时间窗口后，则会被发送至oldevents队列，并结束规则匹配的过程。

输出适配器用于将输出的时间事件序列转化为所需要的格式并发送给已订阅的用户。

在本实施例中，客户端在登录身份验证成功后，通过socket.io库与监控服务器建立一个websocket连接，当前页面js脚本会根据预定义的规则通过监控服务器订阅监控主机的数据(例如订阅ups的实时数据)，监控主机会同时获取客户端的订阅对象内容，并会将满足订阅要求的数据通过监控服务器实时主动推送到web客户端，实现数据自动更新。跳转页面或关闭页面，则会通知服务端清除之前的订阅，回收相关资源。

下面以一个具体的例子做进一步说明：

例如，某电压采样值ua额定值为220v，出于及时预警的需求，用户定义的事件存储规则和事件告警规则为：若ua前后采样值变化幅度超过5％，则立即进行报警通知并存储该采样值。本实施例中的事件存储规则和事件告警规则一致，也可以根据需要让二者不一致，比如若ua前后采样值变化幅度超过10％，才进行报警，或者将事件告警规则定义为其他方式。

监控主机自开始采样连续10次采集到ua的采样值分别为：221v、220.8v、223v、225v、224v、220v、200v、195v、198v、190v。按照用户定义的事件存储规则，第1次采样值满足事件存储规则，被认为是有意义、关键的数据，监控主机会将该次采样值发布至客户端、并同时存储至mongodb数据库。第2次至第6次采样值均不满足事件存储规则和事件告警规则，监控主机不发布、不存储这5次采样值。第6次至第7次采样值变化幅度超过5％，满足事件存储规则和事件告警规则，因此第7次数据被认为是有意义、关键的数据，并被立即发布至监控服务器，通过websocket主动推送采样值ua变化预警至对应订阅的客户端，实现数据的实时刷新。第8次至第10次采样值不满足事件存储规则和事件告警规则，监控主机不发布、不存储这3次采样值，客户端则一直处于变化预警的状态。

由以上举例可以看出，对于10次采样值，在采集端cep引擎的处理下，仅向服务端及客户端上报了两次关键数据，一方面过滤掉了大量处于正常范围且几乎无变化的数据，降低了存储及带宽要求。另一方面由于整个分析处理过程均在内存中完成，实时高效地筛选出了对用户真正有价值的关键数据点，使得用户能够在及时发现潜在问题。

本发明不局限于上述实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。