目前所面临的问题 目前的报警系统只能简单的把用户分为为不同的组,然后每个报警分发至一个和多个组,有的机器或服务的报警并不是每个用户都关心,太多的报警反而会降低警惕心失去报警的意义。
1. 需求分析
本来打算实现分组报警和发送报警至项目负责人两个功能,以及用户按照用户意愿选择想要的接受报警的服务等功能,不过作为一个没正经写过项目小菜同学,还是以做出东西为第一目标。所以此系统第一版只实现以项目负责人为目标的报警分发功能。 思考:每个人都希望自己的产品百分百的完美,但是世上并没有完美的东西,大家都只是在向着完美的方向努力向前而已。
1.1. 需求分析引伸出来的问题
目前我们只能实现一个功能,不过以后慢慢加入其他的功能,为了以后其他功能加入的方便,我们应该尽可能的保证程序的可扩展性。
2. 概要设计
本程序会从接受一个报警信息开始的,每个报警信息经过此系统的分发会发送至不同的用户。所以每个报警信息本身必须带有标记,用于标记自己的属性,比如属于哪个负责人。要把每个报警信息和接收人对应起来,就必须有一个对于关系表,并且此对应关系存储在某个介质上。为了方便起见,此处以文件的形式来存储报警与接收人的对应关系,最后就是以指定的方式发送报警了。所以此系统主要流程有下面三个部分: 1. 报警输入标记 2. 获取报警 3. 获取报警与接收人对应关系 4. 根据标记和对应关系发送报警
3. 详细设计
①报警输入有标记
遇到没标记的情况怎么办:得有默认的发送方式及目标 用户如何自定义标记:以配置的方式把标记的定义放入配置文件中
②获取报警
报警信息的输入只能来自prometheus的alertmanager? 把报警信息的输入设计成一个接口,此接口有一些方法,然后来自alertmanager的报警实现此接口,然后此信息就能被后续的方法获取并处理。
③报警与接收人的对应关系获取
第一版的关系来自于文件,后面的版本有可能来自数据库或者其他存储。所以此处“对应关系”的处理也是一个接口。后面所有的操作依赖此接口
④发送报警
第一版只实现钉钉的发送报警,后面可能实现一些其他的发送方式,所以此处也是接口。
4. 接口设计
接口就等着后面边实现边决定把,现在也没啥思路。毕竟我连接口都没写过呢。
总结
以前写代码,都是......不对,不应该称作代码。。。嗯。。。叫做“脚本“可能更为合适。以前写脚本呀,都是想到那写到哪,也没啥规划,类什么的真心得是懒得写。至于继承。。。作为一个小菜,我还是crtl+c/v搞定吧。毕竟是写脚本嘛,以实现暂时的目标为第一方向。不过现在呢,【我要写代码】了,已经不是简单的脚本了,要有基本的结构,不说什么高内聚,低耦合了,至少也得考虑到简单的扩展吧。当然,依然还只是以实现简单的功能为目标。至于什么并发之类的东东,还是以后版本再考虑吧。不过,即使简单也要有基本的东西。比如日志,配置文件,异常处理~ 第一次写的分析肯定一点都不像个分析,但是呢,就跟写代码一样,总是要迈出第一步的,以后肯定会尽量越来越来哒,代码也会越来越好~就酱!