如何在12个小时，搞定日志监控？

日志监控，是每个公司必须解决的一个问题。创业型公司，如何用半天的时间，搞定一个可扩展，通用的日志监控框架，是今天要聊的话题。

 

什么是日志监控？

关于日志，不同公司，情况不同：

（1）A类公司：没有日志；

（2）B类公司：有日志，只有用户说系统挂了，或者有bug的时候，才会登录到系统看看日志，大部分日志打印得对心所欲，缺乏组织性和系统性；

画外音：很多时候，追查bug发现日志信息不全，要先上线一个有日志的版本，以帮助定位bug。

（3）C类公司：有日志，有日志规范，系统性的组织和收集了日志；

对日志进行监控，先于用户发现系统的故障，实时告警，就是今天要讨论的日志监控问题。

 

日志监控有什么需求？

对于日志的监控，一般有这么几类需求：

（1）某种级别的日志（例如FATAL级别，或者ERROR级别的日志）一旦出现，或者超过一定频率，就告警；

（2）包含某些特殊含义关键字（例如OutOfMemory，或者Exception）的异常日志，一旦出现，或者超过一定频率，就告警；

（3）包含某些特殊含义关键字（例如Login，或者Click）的正常日志，一旦一定时间周期没有出现，就告警；

 

其中，前两类需求，属于异常日志监控范畴，出现异常，实施告警。第三类需求，属于正常日志监控范畴，一定的时间没有出现“正常”，就默认异常，实施告警。

 

为什么不是一出现异常日志就告警呢？

避免抖动引起的误报，一般到达一定频率才会告警，这属于告警策略的一部分。

 

为什么说，目录与日志的规范化，是通用日志监控的前提？

这是一个线上模块的目录示例：

（1）有源代码：hello.c

（2）有可执行文件：a.out

（3）有配置文件：hello.conf

（4）有备份日志：hello.log.2018012812

（5）有日志：hello.log

（6）有临时文件：tmp

体会一下，运维同学看到这样的线上文件部署，是什么感受？