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

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 前面两篇分别说了报警执行器和报警规则的定义及用户扩展加载,接下来就是比较核心的一块了,如何将报警规则和报警执行器关联起来,即当发生报警时,应该call哪一个报警执行器

前面两篇分别说了报警执行器和报警规则的定义及用户扩展加载,接下来就是比较核心的一块了,如何将报警规则和报警执行器关联起来,即当发生报警时,应该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实现)



相关文章
|
20天前
|
安全 前端开发 Android开发
探索移动应用与系统:从开发到操作系统的深度解析
在数字化时代的浪潮中,移动应用和操作系统成为了我们日常生活的重要组成部分。本文将深入探讨移动应用的开发流程、关键技术和最佳实践,同时分析移动操作系统的核心功能、架构和安全性。通过实际案例和代码示例,我们将揭示如何构建高效、安全且用户友好的移动应用,并理解不同操作系统之间的差异及其对应用开发的影响。无论你是开发者还是对移动技术感兴趣的读者,这篇文章都将为你提供宝贵的见解和知识。
|
25天前
|
负载均衡 网络协议 算法
Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式
本文探讨了Docker容器环境中服务发现与负载均衡的技术与方法,涵盖环境变量、DNS、集中式服务发现系统等方式,以及软件负载均衡器、云服务负载均衡、容器编排工具等实现手段,强调两者结合的重要性及面临挑战的应对措施。
58 3
|
3天前
|
安全 搜索推荐 数据挖掘
陪玩系统源码开发流程解析,成品陪玩系统源码的优点
我们自主开发的多客陪玩系统源码,整合了市面上主流陪玩APP功能,支持二次开发。该系统适用于线上游戏陪玩、语音视频聊天、心理咨询等场景,提供用户注册管理、陪玩者资料库、预约匹配、实时通讯、支付结算、安全隐私保护、客户服务及数据分析等功能,打造综合性社交平台。随着互联网技术发展,陪玩系统正成为游戏爱好者的新宠,改变游戏体验并带来新的商业模式。
|
28天前
|
机器学习/深度学习 人工智能 数据处理
【AI系统】NV Switch 深度解析
英伟达的NVSwitch技术是高性能计算领域的重大突破,旨在解决多GPU系统中数据传输的瓶颈问题。通过提供比PCIe高10倍的带宽,NVLink实现了GPU间的直接数据交换,减少了延迟,提高了吞吐量。NVSwitch则进一步推动了这一技术的发展,支持更多NVLink接口,实现无阻塞的全互联GPU系统,极大提升了数据交换效率和系统灵活性,为构建强大的计算集群奠定了基础。
61 3
|
1月前
|
网络协议 网络安全 网络虚拟化
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算。通过这些术语的详细解释,帮助读者更好地理解和应用网络技术,应对数字化时代的挑战和机遇。
106 3
|
27天前
|
前端开发 Android开发 UED
移动应用与系统:从开发到优化的全面解析####
本文深入探讨了移动应用开发的全过程,从最初的构思到最终的发布,并详细阐述了移动操作系统对应用性能和用户体验的影响。通过分析当前主流移动操作系统的特性及差异,本文旨在为开发者提供一套全面的开发与优化指南,确保应用在不同平台上均能实现最佳表现。 ####
27 0
|
1月前
|
存储 自然语言处理 数据可视化
3倍提升效率:医疗病理信息抽取与关系图谱展示系统解析
该项目旨在通过NLP技术将医疗病理报告中的非结构化文本转化为结构化数据,实现信息的高效抽取、存储及可视化展示。利用Python、JavaScript等技术栈,结合Echarts等工具,构建病理信息的关系图谱,支持多条件检索与图表互动,提高医生及研究人员的工作效率。预期成果包括数据结构化、关系图谱可视化、快速检索及数据统计分析等功能。项目预计2-4周完成。
|
2月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
65 3
|
1月前
|
机器学习/深度学习 Android开发 UED
移动应用与系统:从开发到优化的全面解析
【10月更文挑战第25天】 在数字化时代,移动应用已成为我们生活的重要组成部分。本文将深入探讨移动应用的开发过程、移动操作系统的角色,以及如何对移动应用进行优化以提高用户体验和性能。我们将通过分析具体案例,揭示移动应用成功的关键因素,并提供实用的开发和优化策略。
|
2月前
|
域名解析 缓存 网络协议
Windows系统云服务器自定义域名解析导致网站无法访问怎么解决?
Windows系统云服务器自定义域名解析导致网站无法访问怎么解决?

推荐镜像

更多