vlambda博客
学习文章列表

菜鸟级：没有日志。

入门级：有日志，只有用户反馈系统挂了，或者有bug的时候，才会登录到系统看看日志，大部分日志打印得随心所欲，缺乏组织性和系统性；

大虾级：有日志规范，系统性地组织和收集了日志；

画外音：你所在的团队处于哪一级呢？

监控需求分析  

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

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

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

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

为了避免抖动引起误报，我们一般是到达一定频率才会告警。

日志规范

日志规范化是日志监控的前提，常用的日志规范有：

（1）日志分级规范：不同级别的日志打到不同的文件中。

（2）日志切分规范：日志按天或者小时切分，避免出现超大的日志文件，影响查询效率。

（3）日志格式规范：统一格式输出。

集中式 vs 分散式  

日志监控，主要有集中式监控和分散式监控两类思路。

什么是集中式日志监控？

集中式的日志监控，最流行的莫过于ELK了：

（1）各个机器节点上部署logstash，收集日志；

（2）收集的日志汇总到ES；

（3）通过Kibana做统一分析和展现；

什么是分散式日志监控？

ELK有点重，三套系统搭建与运维起来比较麻烦。对于早期的创业型公司，可以采用分散式日志监控。

分散式监控并不统一收集日志，在各个机器上实施日志监控，如果触发监控策略，立刻发起告警

监控框架实现  

言归正传，如何半天搞定一个简单的，可扩展的日志监控框架呢？

框架设计大致分为三个部分：

1、被监控集群

因为我们不统一收集日志，所有日志分散在各个机器中

2、基础信息与服务

我们把需要监控的集群信息和告警发送人信息，写在配置文件里。

集群信息配置文件：

告警责任人配置文件

当需要告警时，我们调用基础的mail.service、SM.service发送通知。

3、日志监控框架

分为两部分：

（1）配置文件log.monitor.conf，保存需要监控的日志项。示例：

（2）核心监控程序

差不多200行代码就可以搞定了。伪代码：

思路比结论重要！