报警系统QuickAlarm之报警规则解析

前面两篇分别说了报警执行器和报警规则的定义及用户扩展加载,接下来就是比较核心的一块了,如何将报警规则和报警执行器关联起来,即当发生报警时,应该call哪一个报警执行器

I. 背景知识点

0. 声明

在正式进入之前,有必要额外声明一下,因为目前的v1版本,没有开放报警规则的自定义,也就是说,目前只支持默认的报警规则,所以接下来的主要内容将集中在

  • 系统默认的报警规则的解析
  • 即基于报警频率阀值,自动选择报警执行器的规则解析

1. 报警规则

如果对于报警规则,依然不是很清晰的,可以阅读一下《报警系统QuickAlarm之报警规则的设定与加载》

这里简单的进行说明,系统中默认的报警规则结构为:

  • key为报警类型(即用户执行报警时,传进来的报警类型参数)
  • value为具体报警规则
    • 每个报警执行器拥有一个报警频率区间,通过报警频率映射到报警执行器的区间来选择对应的AlarmExecutor,这就是系统定义的报警规则

II. 报警规则解析

通过前面的报警规则的简单说明,基本上也可以捞出报警规则的解析原则了

  • 每种报警类型,对应一个报警规则
  • 每个报警规则中,可以有多个报警执行器
  • 每个报警执行器都有一个对应的报警频率的阀值
  • 根据阀值对所有的报警执行器排序
  • 计算报警频率,映射到哪个区间,则选择哪个报警执行器

上面是一个简单的解析规则,当然实际上和这个差不多,但有一些问题需要额外注意

  1. 只想选择一种报警方式,是否可以支持?
  2. 多重报警方式同时调用怎么处理?(如我希望用短信提示说有问题,同时用邮件包含详细的异常堆栈)
  3. 频率限制
  4. 报警类型没有设置报警规则如何处理?
  5. 报警规则中使用了一个未注册的报警执行器会怎样?

1. 实现方案说明

再次将报警规则类拿出来看一下

/**
 * 报警用户
 */
private List<String> users;


/**
 * 报警的阀值
 */
private List<AlarmThreshold> alarmThreshold;


/**
 * 最小的报警数
 */
private int minLimit;


/**
 * 最大的报警数
 */
private int maxLimit;


/**
 * 报警类型 {@link IExecute#getName()}
 */
private String alarmLevel;


/**
 * true 表示当报警超过当前的阀值之后, 将提升报警的程度
 */
private boolean autoIncEmergency;
复制代码

针对上面的问题,逐一说明

  • 首先是 autoIncEmergency 这个参数,如果为true,则表示可以走上面的哪个区间映射的规则;否则就全部走AlarmConfig中默认的报警类型了
  • minLimit : 表示发生报警的频率下限值,小于这个值就不会执行具体的报警逻辑
  • maxLimit : 最大的报警频率,超过了也不报警(简单的频率控制)
  • alarmLevel: 对应的就是具体的报警类型
  • alarmThreshold: 这个只有在autoIncEmergency=true时,才有小,也就是我们前面说的不同的报警执行器,根据阀值区间进行排序,开启之后,遍历,判断频率是否在这个区间内,若在,则表示可以选择它了
  • 如果不存在报警规则,则采用默认的兜底规则
  • 若报警执行器也不存在,就直接采用系统定义的日志报警执行器

2. 实现

基本上前面已经将整个逻辑都说了,所以实际的编码反而比较清晰了

/**
 * 获取具体的报警执行器
 * <p>
 * 1. 未开启严重等级上升时, 直接返回
 * 2. 开启之后, 判断当前的计数 范围
 *
 * @param alarmConfig 报警配置项, 内部所有的参数都不可能为null
 */
public static ExecuteHelper getExecute(final AlarmConfig alarmConfig, 
  int count) {
    // 未达到报警的下限 or 超过报警的上限时
    if (count < alarmConfig.getMinLimit() || count > alarmConfig.getMaxLimit()) {
        return new ExecuteHelper(SimpleExecuteFactory.getExecute(NoneExecute.NAME), 
        alarmConfig.getUsers());
    }

    // 未开启报警升级, 直接返回
    if (!alarmConfig.isAutoIncEmergency()) {
        return new ExecuteHelper(SimpleExecuteFactory.
          getExecute(alarmConfig.getAlarmLevel()),
          alarmConfig.getUsers());
    }


    // 报警等级开启上升之趋势
    // 1. 获取设置的默认等级
    // 2. 判断当前的报警次数, 选择对应的报警类型
    // 3. 选择具体的报警类型
    String defaultLevel = alarmConfig.getAlarmLevel();
    String selectLevel = null;
    List<String> selectUser = alarmConfig.getUsers();

    List<AlarmThreshold> list = alarmConfig.getAlarmThreshold();
    boolean useNew = false;
    boolean containDefaultLevel = false;
    for (AlarmThreshold alarmThreshold : list) {
        if (Objects.equals(alarmThreshold.getAlarmLevel(), defaultLevel)) {
            containDefaultLevel = true;
        }
    }


    for (AlarmThreshold alarmThreshold : list) {
        // 表示当前的报警等级已经赶上默认的报警等级了, 所以要选择新的报警类型
        if (Objects.equals(alarmThreshold.getAlarmLevel(), defaultLevel)) {
            useNew = true;
        }

        if (count < alarmThreshold.getThreshold()) {
            break;
        }

        selectLevel = alarmThreshold.getAlarmLevel();
        // 选择新的报警类型时, 需要更新报警用户
        selectUser = alarmThreshold.getUsers(); 
    }


    // 阀值列表中不包含默认报警类型,则根据新的来
    if (!containDefaultLevel && selectLevel != null) {
        return new ExecuteHelper(SimpleExecuteFactory.getExecute(selectLevel), selectUser);
    }


    // 如果阀值列表中包含了默认报警类型, 且已经超过默认阀值
    if (useNew && selectLevel != null) {
        return new ExecuteHelper(SimpleExecuteFactory.getExecute(selectLevel), selectUser);
    } else {
        return new ExecuteHelper(SimpleExecuteFactory.getExecute(defaultLevel), alarmConfig.getUsers());
    }
}
复制代码

具体的实现基本和我们前面分析的一样,但有一个地方需要额外注意

  • 默认报警阀值,可以直接决定是否需要报警
  • 因此定义的其他报警方式的阀值,应该在默认的阀值区间内
  • 当然AlarmThreshold中不包含默认报警方式时,优先选择阀值区间的报警方式
  • 当然AlarmThreshold中包含默认报警方式时,根据新的规则做处理

(吐槽:上面这个实现有点绕,后面想办法规避下,搞得不太好理解了)

另外一个问题就是,上面的实现没有支持可以同时选择多个报警执行器的情况

因为考虑到后面肯定会对报警规则的定义和解析放开,所以先实现了一个简单的场景,具体的放在后面处理

III. 小结

到这里报警规则和报警执行器之间的解析关系已确定,剩下的东西就简单了,一个维持报警频率计数,一个报警线程池,再加上一个对外接口的封装而言

基本上,到这里主要的核心逻辑已经完成,小结一下本系统中的核心设计理念 -- 一切可自定义(当然目前差得有点远)

1. 报警执行器

  • 通过SPI机制支持用户自定义扩展
  • 要求 Executor 拥有唯一标识
  • 因为报警执行器支持扩展,所以Executor的内部实现,完全可以由用户决定

2. 报警规则

  • 目前报警规则只提供默认的基于频率区间的选择方案
  • 报警规则通过报警执行器的name与之唯一对应,若对应不上,则选择默认执行器
  • 报警规则的加载同样基于SPI,支持自定义,因此报警规则可以存在任何地方
  • 报警规则加载器,提供一个报警规则变动的钩子(load()),若采用自定义的加载类,则确保规则变动时,主动回调这个方法
  • 默认的报警规则加载类,是基于系统的配置文件实现,内部托管了文件的变动更新事件(使用commons-io实现)

IV. 其他

相关博文

  1. 报警系统QuickAlarm总纲
  2. 报警系统QuickAlarm之报警执行器的设计与实现
  3. 报警系统QuickAlarm之报警规则的设定与加载
  4. 报警系统QuickAlarm之报警规则解析
  5. 报警系统QuickAlarm之频率统计及接口封装
  6. 报警系统QuickAlarm使用手册

项目: QuickAlarm

个人博客: Z+|blog

基于hexo + github pages搭建的个人博客,记录所有学习和工作中的博文,欢迎大家前去逛逛

声明

尽信书则不如,已上内容,纯属一家之言,因本人能力一般,见识有限,如发现bug或者有更好的建议,随时欢迎批评指正,我的微博地址: 小灰灰Blog

扫描关注

QuickAlarm直接使用Window Media Player的COM组件及进行音频播放,也就是说你手机上WMP支持多少种格式,快速闹钟也将支持这些格式。如:.wma、.mp3、.mpeg、.avi、.wmv、.asf、.wav、.mid、.mid、.midi、.wm、.mpg、.m1v、 .mp2、.mpa、.rm、.3gp等目前绝大部分文件格式,当然有些是要求你安装了插件才行的,如现在流行rm插件。同时目前的PPC2003、WM5、WM6都可很好的支持以上文件。(PPC2003因WMP本身不支持WAV,所以此系统的用户们注意了。) 注:目前视频文件将只可以听到声音,以后将会在闹钟提醒界面支持视频。引用: 闹钟定时说明: 1。每周定时:   这个我想大家都知道的,选择你在一周内所有定时的日,每天选项意在提供快速选择一周内的七天。初始为每天。 2。每月定时:(支持农历)   在每月指定日将会启闹,如:设为5日,每月的5日其设定时间都会启闹,连续天数是在这5日起的N天内都有效。农历每月是一样的意思,同时每月定时支持两个定时日,意思一样,方便初一、十五类似的定时。 3。指定定时:(支持农历)   这个很好理解,不用多说。说下指定定时中的每年选项,这个选项适合定时生日或纪念日的朋友,先设置好起始年,再打上每年选项的勾,闹钟注释的内容中第一个"%d"的标志将被转换成当前年到您设置的起始年的差值,如:设为1982年,注释为"%d周岁生日",这样今年闹钟就会显示为:26周岁生日。以此类推。 4。周期定时:(支持农历)   是指从设定日起开启闹钟N天,然后关闭闹钟N天,之后重复,如果勾上每月的话,则每月在指定日都将重置,就是说循环周期将重新开始。农历是同样的意思,这个适合倒班的朋友。在农村赶圩,是逢一、六;二、七之类的,这样农历周期定时就用上场了,如逢一、六:设置为:农历、每月、指定日初一,开1天、关4天。引用: 重要声明:   有朋友反应会有不闹,或是出现异常问题。当您也出现这些问题时,请确认你是否将QuickAlarm放在了卡上。因存储卡在从休眠启动瞬间是无法正常使用的,所以在将QuickAlarm放在卡上,出现异常是在所能免的。其它闹钟软件多数解决方法都是将一个程序复制到Windows目录下,也就是QuickAlarm中的QAlarm文件。但现在QAlarm无法单独执行。请将QuickAlarm整个文件夹复制到您的手机内存里。以保证安全运行,不会出现不闹现象。(如果您觉得文件大,可将报时文件去掉。) 1.2   1:还原1.0版本高级选项,解决部分机型关机现象;   2:编辑框添加右键菜单的支持,提高方便性;   3:今日插件支持右键菜单操作,可关闭打开所有闹钟;   4:修复上版本一些小BUG;   5:标准化插件,提供定时程序插件源码,方便有能力者编写更好的插件。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值