实时告警系统（一）

 今天经理告诉小明（程序员），你做的功能为啥不能用了？于是小明，联系小红童鞋（运维）说你帮我看看线上日志呗，小红童鞋用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时间

项目的意义

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

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