报警系统QuickAlarm之频率统计及接口封装

简介: 前面将报警规则的制定加载解析,以及报警执行器的定义加载和扩展进行了讲解,基本上核心的内容已经完结,接下来剩下内容就比较简单了1.报警频率的统计2.报警线程池3.对外封装统一可用的解耦

前面将报警规则的制定加载解析,以及报警执行器的定义加载和扩展进行了讲解,基本上核心的内容已经完结,接下来剩下内容就比较简单了


  • 报警频率的统计
  • 报警线程池
  • 对外封装统一可用的解耦


I. 报警频率统计



1. 设计


前面在解析报警规则时,就有一个count参数,用来确定具体选择什么报警执行器的核心参数,我们维护的方法也比较简单:


  • 针对报警类型,进行计数统计,没调用一次,则计数+1
  • 每分钟清零一次


2. 实现


因为每种报警类型,都维护一个独立的计数器


定义一个map来存储对应关系

private ConcurrentHashMap<String, AtomicInteger> alarmCountMap;
复制代码


每分钟执行一次清零

// 每分钟清零一把报警计数
ScheduledExecutorService scheduleExecutorService = Executors.newScheduledThreadPool(1);
scheduleExecutorService.scheduleAtFixedRate(() -> {
    for (Map.Entry<String, AtomicInteger> entry : alarmCountMap.entrySet()) {
        entry.getValue().set(0);
    }
}, 0, 1, TimeUnit.MINUTES);
复制代码


注意上面的实现,就有什么问题?


有没有可能因为map中的数据过大(或者gc什么原因),导致每次清零花不少的时间,而导致计数不准呢? (先不给出回答)


计数加1操作

/**
 * 线程安全的获取报警总数 并自动加1
 *
 * @param key
 * @return
 */
private int getAlarmCount(String key) {
    if (!alarmCountMap.containsKey(key)) {
        synchronized (this) {
            if (!alarmCountMap.containsKey(key)) {
                alarmCountMap.put(key, new AtomicInteger(0));
            }
        }
    }
    return alarmCountMap.get(key).addAndGet(1);
}
复制代码


II. 报警线程池



目前也只是提供了一个非常简单的线程池实现,后面的考虑是抽象一个基于forkjoin的并发框架来处理(主要是最近接触到一个大神基于forkjoin写的并发器组件挺厉害的,所以等我研究透了,山寨一个)


// 报警线程池
private ExecutorService alarmExecutorService = new ThreadPoolExecutor(3, 5, 60,
        TimeUnit.SECONDS,
        new LinkedBlockingDeque<>(10), 
        new DefaultThreadFactory("sms-sender"),
        new ThreadPoolExecutor.CallerRunsPolicy());
复制代码


任务提交执行

private void doSend(final ExecuteHelper executeHelper, 
  final AlarmContent alarmContent) {
    alarmExecutorService.execute(() ->
      executeHelper.getIExecute().sendMsg(
        executeHelper.getUsers(), 
        alarmContent.getTitle(), 
        alarmContent.getContent()));
}
复制代码


III. 接口封装



这个就没什么好说的了


public void sendMsg(String key, String content) {
    sendMsg(new AlarmContent(key, null, content));
}
public void sendMsg(String key, String title, String content) {
    sendMsg(new AlarmContent(key, title, content));
}
/**
 * 1. 获取报警的配置项
 * 2. 获取当前报警的次数
 * 3. 选择适当的报警类型
 * 4. 执行报警
 * 5. 报警次数+1
 *
 * @param alarmContent
 */
private void sendMsg(AlarmContent alarmContent) {
    try {
        // get alarm config
        AlarmConfig alarmConfig = confLoader.getAlarmConfig(alarmContent.key);
        // get alarm count
        int count = getAlarmCount(alarmContent.key);
        alarmContent.setCount(count);
        ExecuteHelper executeHelper;
        if (confLoader.alarmEnable()) { // get alarm execute
            executeHelper = AlarmExecuteSelector.getExecute(alarmConfig, count);
        } else {  // 报警关闭, 则走空报警流程, 将报警信息写入日志文件
            executeHelper = AlarmExecuteSelector.getDefaultExecute();
        }
        // do send msg
        doSend(executeHelper, alarmContent);
    } catch (Exception e) {
        logger.error("AlarmWrapper.sendMsg error! content:{}, e:{}", alarmContent, e);
    }
}
复制代码


接口封装完毕之后如何使用呢?


我们使用单例模式封装了唯一对外使用的类AlarmWrapper,使用起来也比较简单,下面就是一个测试case


@Test
public void sendMsg() throws InterruptedException {
    String key = "NPE";
    String title = "NPE异常";
    String msg = "出现NPE异常了!!!";
    AlarmWrapper.getInstance().sendMsg(key, title, msg);  // 微信报警
    // 不存在异常配置类型, 采用默认报警, 次数较小, 则直接部署出
    AlarmWrapper.getInstance().sendMsg("zzz", "不存在xxx异常配置", "报警嗒嗒嗒嗒");
    Thread.sleep(1000);
}
复制代码


使用起来比较简单,就那么一行即可,从这个使用也可以知道,整个初始化,就是在这个对象首次被访问时进行


构造函数内容如下:

private AlarmWrapper() {
  // 记录每种异常的报警数
  alarmCountMap = new ConcurrentHashMap<>();
  // 加载报警配置信息
  confLoader = ConfLoaderFactory.loader();
  // 初始化线程池
  initExecutorService();
}
复制代码


所有如果你希望在自己的应用使用之前就加载好所有的配置,不妨提前执行一下 AlarmWrapper.getInstance()


IV. 小结



基于此,整个系统设计基本上完成,当然代码层面也ok了,剩下的就是使用手册了

再看一下我们的整个逻辑,基本上就是下面这个流程了

image.png


  1. 提交报警
  • 封装报警内容(报警类型,报警主题,报警内容)
  • 维护报警计数(每分钟计数清零,每个报警类型对应一个报警计数)


  1. 选择报警
  • 根据报警类型选择报警规则
  • 根据报警规则,和当前报警频率选择报警执行器
  • 若不开启区间映射,则返回默认执行器
  • 否则遍历所有执行器的报警频率区间,选择匹配的报警规则


  1. 执行报警
  • 封装报警任务,提交线程池
  • 报警执行器内部实现具体报警逻辑


作者:一灰灰

链接:https://juejin.cn/post/6844903569456365576

来源:稀土掘金

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

相关文章
|
4月前
|
Prometheus 监控 关系型数据库
|
SQL 缓存 负载均衡
线上cpu报警的一次接口优化
春天到了大地都复苏了,沉寂了很久的cpu也开始慢慢复苏了,所谓前人埋坑后人填坑,伴随着阿里云监控报警,线上CPU使用率暴增,于是就开始了排查之路。
|
19天前
|
SQL JSON 监控
无需重启应用,动态采集任意点位日志
现实系统往往有着较高的复杂度,我们借助Trace、Log、Metric三驾马车使我们的系统具备了一定的可观测性,但观测位置和信息往往是固定的,而我们所遇到的问题常常是意料之外的,这就导致我们能够定位问题的范围,但是难以更进一步,这时候我们就需要在我们想要的位置采集信息来帮助我们,在通常的实践中这就意...
33 0
无需重启应用,动态采集任意点位日志
|
存储 JSON 数据格式
报警系统QuickAlarm之报警规则的设定与加载
既然命名为规则,那么就需要有对应的解析器,以根据报警规则和报警类型等相关输入条件,来选择对应的报警执行器,因此本文主要包括的内容就比较清晰了 1.报警规则的定义 2.报警规则的加载 3.报警规则的解析以及报警执行器选择
218 0
报警系统QuickAlarm之报警规则的设定与加载
|
缓存 Java Spring
报警系统QuickAlarm之报警执行器的设计与实现
根据前面一篇总纲的博文,将整体结构划分为了四大块,本文则主要目标集中在第一块,报警执行器(AlarmExecute)的设计与加载上了 主要的关注点无外乎 定义-》加载-》实现逻辑三块了: 1.AlarmExecute 的接口定义 2.如何加载用户自定义的AlarmExecute 3.AlarmExecute的内部实现
279 0
报警系统QuickAlarm之报警执行器的设计与实现
|
JSON 应用服务中间件 nginx
自动化测试之统计手工测试期间的接口响应时间
filebeat采集nginx的日志,以json格式解析后传入elasticsearch,全部字段都是text格式,我们需要把request_time变成double格式才能使用聚合搜索request_time的最大值. 1.获得老索引的mapping信息 2.用这个mapping信息新建一个索引 3.用reindex方法,把老索引的数据迁移到新索引 4.确认新索引数据迁移成功 5.删除老索引 6.获得出新索引的mapping 7.使用新索引的mapping创建老索引 8.把新索引的数据倒回老索引 9.删除老索引
308 0
自动化测试之统计手工测试期间的接口响应时间
|
SQL 运维 监控
监控异常操作频率并报警
当企业上云后,监控云资源的异常操作就是一件非常重要的事情。如何监控这些异常操作呢?答案就是操作审计。接下来就以一些实际场景为例,介绍如何基于操作审计,监控云上异常操作或操作频率,进行报警。
监控异常操作频率并报警
|
应用服务中间件 PHP nginx