实时告警系统(一)

今天经理告诉小明(程序员),你做的功能为啥不能用了?于是小明,联系小红童鞋(运维)说你帮我看看线上日志呗,小红童鞋用SSH链接到生产环境,打开后台日志,一看发现确实抛了一个异常,原因是数据库字段太短,数据存不进去,之后事情就这么愉快的解决了!一次两次还好,如果时间久了,你就得一直麻烦小红童鞋帮这看看日志。而且经理他们只看结果,根本不管你是什么问题导致的,长期下来就会对你的能力有质疑;针对这个问题,小明决定做一个日志监控告警系统,在经理发现问题之前就提前发现问题并解决掉

架构设计

1.基础产生日志的项目,最少也得有一个。

2.flume 是一个分布式日志收集工具,因其简单易用赢得人们青睐,系统使用FLUME收集来自各个子系统中产生的日志,这个日志可以是log4J产生的,具体情况视公司而定;

3.kafka 是一个分布式的消息队列,底层用scala编写,其中提供生产者和消费者的功能,他提供类似JMS的特性,我们创建一个Topic,Flume sink到kafka 的这个topic 中

4.storm 是一个分布式的流式计算框架,每个topology中并行运行着很多个bolt,整个工作流程似流水一样,从源头源源不断的就像终点。我们使用kafkaSpout获取kafka中的数据,对数据进行过滤、根据匹配规则完成日志匹配,完成发送邮件或者手机短信,来通知模块负责人。

5.数据库方面我们可以选用mysql,项目启动后需要把规则加载到storm内存,与此同时做一个定时任务完成更新storm内存中的规则,如果公司项目很大很大,规则很多的话可以考虑用redis,如果很少的话考虑使用mysql即可。

6.zookeeper 是一个分布式协调工具

数据库设计

1.用户表,用来记录用户基本信息,比如姓名,邮箱,手机号等基本信息

2.应用表,用来记录公司的所有子系统

3.规则表,关键字段所属应用、负责人、匹配字符

4.异常记录表:发现异常信息后触发存储异常记录操作。

逻辑梳理

下面主要阐述项目中核心部分逻辑以及注意点:

1.项目启动后首先需要加载 APP对应的负责人列表、用户列表、APP的异常匹配规则、APP列表

2.数据进入第一层的Bolt后,对数据进行规整和过滤,常规的操作是将数据转成一个JavaBean。

3.匹配JavaBean是否满足异常匹配规则

4.满足规则,根据appId找到对应负责人,发送邮件和手机短信通知

5.将异常记录信息存放到mysql数据库


下面阐述定时任务的核心逻辑以及注意点:

1.什么时候同步数据比较好? 如果同步任务写成定时任务,加入kafka中根本就没有数据过来,就算再怎么同步其实也没什么用,所以我们规定只有kafka中有数据过来,这边才跑定时任务。

2.检测kafka有没有数据其实很简单,第一次FirstBolt的 execute方法只要触发,就证明有数据,那么我们又不想让他每次都触发更新操作,需要怎么办?

- 定义reload boolean全局字段,在非load时间一直修改reload字段为true,在load时间修改reload为false即可;
- load规则的时候,需要加上同步操作。

load时间:比如定义只要当前时间能被10整除就是load时间,非load时间比如定义只要当前时间不能被10整除就是非load时间

项目的意义

辅助增强系统稳定性,如果内部人员总能在第一时间内发现问题,在其他人发现问题之前就能把问题解决了,长期如此用户对公司产品的认可度也会提升。

将系统日志信息记录到数据库,并且设置触发时间以及解决时间,并生成报表。为将来绩效考核做一个数据支撑。用告警系统推动整个部门的积极性,使公司能够更加平稳的发展。