一种分布式的告警规则引擎设计方法与流程

本发明涉及船舶交通管理领域，特别是一种分布式的告警规则引擎设计方法。

背景技术：

船舶交通管理系统的本质在于为辖区内的过往船舶提供安全的助航服务。目前雷达、ais、cctv等多种传感器设备已经在船舶交通管理系统中得到了普遍应用，并持续提供大量的船舶实时动静态数据。通过这些动静态数据在电子海图上的实时展示、更新，值班人员能够掌握水面状况并做相应的态势判断，从而为过往船舶提供助航服务。

告警在船舶交通管理系统中是一个比较重要的功能，反映出系统智能化水平的程度。系统对重点区域、重点船舶的行为进行有效监测，比如锚地中锚泊船走锚、航道中危险船舶的会遇等等，都能够及时感知并实时推送告警提示信息。但目前船舶交通管理系统中告警功能还普遍没有充分利用船舶的动静态数据，感知判断能力还很有限。传统的船舶交通管理系统中没有考虑到用户的订阅思想，所有的客户端共享一份告警数据，不能针对性地按实际需要推送告警数据。同时随着船舶实时数据越来越多，系统的智能化水平要求越来越高，系统的处理能力不能支撑各种规则、业务判断的性能要求。

为适应海事智能化监管的趋势，提升系统对大数据的处理能力和感知能力，通过大数据分析加强系统对重点关注船舶告警判断的有效性和准确性，分布式的告警规则引擎显得更为迫切需要。

技术实现要素：

本发明要解决的技术问题是针对上述现有技术的不足，而提供一种分布式的告警规则引擎设计方法，该分布式的告警规则引擎设计方法能实现根据用户的实际订阅需求提供告警服务功能，并能够根据用户在线数量调整告警负载的动态均衡分配，实现大数据、多用户的告警服务。

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

一种分布式的告警规则引擎设计方法，包括如下步骤。

步骤1，告警类型数据库建立：根据数理统计，建立告警类型数据库，该告警类型数据库包括各种告警类型以及每种告警类型所需占用的cpu资源消耗值。

步骤2，用户订阅管理系统建立：用户订阅管理系统服务器与每个订阅用户均建立通信协议，时刻维护当前在线的订阅用户个数；用户订阅管理系统中布设多个告警处理引擎。

步骤3，用户订阅区域及区域告警规则建立：每个订阅用户均能根据自身需求建立订阅区域以及每个订阅区域内的告警规则。

步骤4，用户订阅管理，包括如下步骤。

步骤41，用户订阅区域及区域告警规则加载：用户订阅管理系统自动识别在线订阅用户，并通过数据接口调用加载各个在线订阅用户所建立的订阅区域及告警规则信息。

步骤42，单个在线订阅用户cpu资源消耗值计算：根据步骤1中每种告警类型所需占用的cpu资源消耗值，将每个在线订阅用户所建立的所有订阅区域内所有告警类型所需占用的cpu资源消耗值相加，从而计算出对应在线订阅用户cpu资源消耗值。

步骤5，告警处理引擎分配：用户订阅管理系统根据识别的在线订阅用户数量及计算得出的单个在线订阅用户cpu资源消耗值，将所有在线订阅用户分配至多个告警处理引擎中。

步骤6，告警处理引擎线程开辟：每个告警处理引擎，根据步骤5分配的在线订阅用户的负载情况，开辟对应的处理线程个数，进行告警规则的判断和消息推送。

步骤7，船舶实时数据接收与分发：用户订阅管理系统实时接收船舶动态跟踪数据并进行分发至多个告警处理引擎中。

步骤8，告警规则判断：每个告警处理引擎中的处理线程，根据接收到的船舶动态跟踪数据，进行每个订阅区域内所有告警规则的实时计算，并推送生成的告警信息至相应在线订阅用户；同时，将生成的告警信息存入告警信息数据库。

还包括步骤9，根据订阅用户在线、离线及新增情况，订阅区域和/或告警规则的增减情况，重复步骤3至步骤8，实现对所有在线订阅用户所有订阅区域内各种告警规则的判断和信息服务功能。

步骤42中，单个在线订阅用户cpu资源消耗值u的计算方法如下。

步骤42a)，假设告警处理引擎的个数为s，则n个当前在线订阅用户集合为{12…i…n}，i＜n；其中，第i个订阅用户所建立的m个订阅区域集合为{ai1ai2…aiy…aim}，y＜m；第y个订阅区域内h个告警规则的cpu资源消耗集合为{cy1cy2…cyh}。

步骤42b)，第i个订阅用户第y个订阅区域内h个告警规则的cpu资源消耗计算如下：

aiy＝cy1+cy2+…+cyh

式中，cy1、cy2……cyh的具体值通过从步骤1中建立的告警类型数据库中查找获取。

步骤42c)，第i个在线订阅用户m个订阅区域内的总cpu资源消耗值ui计算如下：

ui＝ai1+ai2+…aiy+…+aim

式中，ai1、ai2……aim的计算方法与aiy的计算方法同。

步骤5中，采用采用双游标滑动法，将所有在线订阅用户分配至多个告警处理引擎中。

步骤5中，双游标滑动法，包括如下步骤。

步骤51，当前所有在线订阅用户cpu资源消耗值排序：根据步骤42计算的单个在线订阅用户cpu资源消耗值，将当前所有在线订阅用户cpu资源消耗值按照由大到小的顺序进行排序，并以填充矩形条的长短进行标识；填充矩形条越长表示该在线订阅用户cpu资源消耗值越大。

步骤52，告警处理引擎剩余处理能力排序：对所有告警处理引擎的剩余处理能力进行评估并按照从大到小的顺序进行排序，同样以填充矩形条的长短进行标识；此处，填充矩形条越长表示告警处理引擎的剩余处理能力越大。

步骤53，通过双游标分别在所有在线订阅用户cpu资源消耗值排序的两端对向滑动的方式，给各告警处理引擎分配在线订阅用户，直到所有在线订阅用户全部分配结束。

步骤2中，用户订阅管理系统服务器与每个订阅用户建立的通信协议采用心跳机制进行保证。

步骤41中，用户订阅管理系统通过webservice数据接口调用加载各个在线订阅用户所建立的订阅区域及告警规则信息。

步骤3中，建立的订阅区域包含点、直线、折线、圆、椭圆、矩形及闭合多边形。

步骤3中，建立的告警规则包含与固定点的距离计算、穿越线形区行为、进入或离开闭合区域行为、碰撞告警、会遇告警、追越告警和领域入侵告警中的一种或多种。

本发明具有如下有益效果：本发明能够根据用户的实际订阅需求提供告警服务功能，并能够根据用户在线数量调整告警负载的动态均衡分配，实现大数据、多用户的告警服务，主要的创新点在于结合告警复杂度和用户订阅数提出分布式告警概念,并通过用户分配机制合理运用计算资源实现告警的推送服务。

附图说明

图1显示了本发明一种分布式的告警规则引擎设计方法的流程示意图。

图2显示了用户订阅管理系统服务器与每个订阅用户的通信方式。

图3显示了建立的告警规则类型的示意图。

图4显示了当前所有在线订阅用户cpu资源消耗值排序示意图。

图5显示了告警处理引擎剩余处理能力排序示意图。

图6显示了采用双游标滑动法将多个在线订阅用户分配至告警处理引擎的示意图。

具体实施方式

下面结合附图和具体较佳实施方式对本发明作进一步详细的说明。

如图1所示，一种分布式的告警规则引擎设计方法，包括如下步骤。

步骤1，告警类型数据库建立。

根据数理统计，建立告警类型数据库，该告警类型数据库包括各种告警类型以及每种告警类型所需占用的cpu资源消耗值。如基于大量计算统计的基础上得出的平均值，作为每种告警类型所需占用的cpu资源消耗值。

步骤2，用户订阅管理系统建立。

用户订阅管理系统服务器与每个订阅用户均建立通信协议，如图2所示，优选采用心跳机制进行保证，时刻维护当前在线的订阅用户个数；用户订阅管理系统中布设多个告警处理引擎(也称告警引擎)。其中，订阅用户个数远大于告警处理引擎的个数。

步骤3，用户订阅区域及区域告警规则建立。

每个订阅用户均能根据自身需求建立订阅区域以及每个订阅区域内的告警规则。

如图3所示，建立的订阅区域包含点、直线、折线、圆、椭圆、矩形及闭合多边形等各种形状。形状不同，点的集合则有差异。

另如图3所示，建立的告警规则包含与固定点的距离计算、穿越线形区行为、进入或离开闭合区域行为、碰撞告警、会遇告警、追越告警和领域入侵告警等告警类型中的一种或多种。当然，本发明的告警规则不限于图3中的告警类型。

步骤4，用户订阅管理，包括如下步骤。

步骤41，用户订阅区域及区域告警规则加载：用户订阅管理系统自动识别在线订阅用户，并通过数据接口，如webservice数据接口，调用加载各个在线订阅用户所建立的订阅区域及告警规则信息。

步骤42，单个在线订阅用户cpu资源消耗值计算：根据步骤1中每种告警类型所需占用的cpu资源消耗值，将每个在线订阅用户所建立的所有订阅区域内所有告警类型所需占用的cpu资源消耗值相加，从而计算出对应在线订阅用户cpu资源消耗值。

单个在线订阅用户cpu资源消耗值u的计算方法优选如下。

步骤42a)，假设告警处理引擎的个数为s，则n个当前在线订阅用户集合为{12…i…n}，i＜n；其中，第i个订阅用户所建立的m个订阅区域集合为{ai1ai2…aiy…aim}，y＜m；第y个订阅区域内h个告警规则的cpu资源消耗集合为{cy1cy2…cyh}。

步骤42b)，第i个订阅用户第y个订阅区域内h个告警规则的cpu资源消耗计算如下。

aiy＝cy1+cy2+…+cyh

式中，cy1、cy2……cyh的具体值通过从步骤1中建立的告警类型数据库中查找获取。

步骤42c)，第i个在线订阅用户m个订阅区域内的总cpu资源消耗值ui计算如下：

ui＝ai1+ai2+…aiy+…+aim

式中，ai1、ai2……aim的计算方法与aiy的计算方法同。

另外，用户订阅管理还包括对在线用户的分配、对离线用户的销毁等。

步骤5，告警处理引擎分配。

用户订阅管理系统根据识别的在线订阅用户数量及计算得出的单个在线订阅用户cpu资源消耗值，并优选采用采用双游标滑动法，将所有在线订阅用户分配至多个告警处理引擎中。

上述双游标滑动法，优选包括如下步骤。

步骤51，当前所有在线订阅用户cpu资源消耗值排序(也称订阅用户排序)。

根据步骤42计算的单个在线订阅用户cpu资源消耗值，将当前所有在线订阅用户cpu资源消耗值按照由大到小的顺序进行排序，并以填充矩形条的长短进行标识，如图4所示，其中，填充矩形条越长表示该在线订阅用户cpu资源消耗值越大。

步骤52，告警处理引擎剩余处理能力排序(也称告警处理引擎排序)。

对所有告警处理引擎的剩余处理能力进行评估并按照从大到小的顺序进行排序，同样以填充矩形条的长短进行标识，如图5所示，填充矩形条越长表示告警处理引擎的剩余处理能力越大。

步骤53，如图6所示，通过双游标分别在所有在线订阅用户cpu资源消耗值排序的两端对向滑动的方式，给各告警处理引擎分配在线订阅用户。由于正常订阅用户的数目要远远大于告警处理引擎的个数，所以游标滑动的过程中会反复地给处理引擎分配用户，即游标1滑动过程中所有引擎都会分配到用户，然后游标后续滑动会从处理能力最大的引擎开始依次再次分配用户，依此逻辑循环执行分配任务，游标2同样的原理，直到所有在线订阅用户全部分配结束。本发明中，以在线订阅用户为最小的分配单元进行负载均衡的分配，不考虑把单个用户进行拆分分配到多个告警引擎处理单元中。

步骤6，告警处理引擎线程开辟：每个告警处理引擎，根据步骤5分配的在线订阅用户的负载情况，开辟对应的处理线程个数，进行告警规则的判断和消息推送。

步骤7，船舶实时数据接收与分发：用户订阅管理系统实时接收船舶动态跟踪数据并进行分发至多个告警处理引擎中。

步骤8，告警规则判断：每个告警处理引擎中的处理线程，根据接收到的船舶动态跟踪数据，进行每个订阅区域内所有告警规则的实时计算，并推送生成的告警信息至相应在线订阅用户；同时，将生成的告警信息存入告警信息数据库。

步骤9，根据订阅用户在线、离线及新增情况，订阅区域和/或告警规则的增减情况，重复步骤3至步骤8，实现对所有在线订阅用户所有订阅区域内各种告警规则的判断和信息服务功能。

综上所述，本发明重点在于各告警规则复杂度的计算方法和用户资源分配的方法，包括根据告警规则计算复杂度确定单个区域资源消耗，并推广到单个用户cpu资源消耗的计算方法，最后根据告警引擎的计算能力合理分配用户，达到较好的告警服务功能。另外，随着后续多传感器数据量的增加以及用户数量的增长，分布式告警规则引擎设计保证各处理引擎负载达到相对动态均衡，确保为在线用户提供持续的定制化告警服务。

以上详细描述了本发明的优选实施方式，但是，本发明并不限于上述实施方式中的具体细节，在本发明的技术构思范围内，可以对本发明的技术方案进行多种等同变换，这些等同变换均属于本发明的保护范围。