如何在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

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

画外音：没见过源代码直接部署到线上的？

 

有什么常见的目录规范呢？

目录规范化不但对日志监控，对自动化运维都极为重要，要是线上目录都瞎搞，几乎没有办法实现自动化运维。

常见的目录规范有两类：

（1）模块优先类目录规范；

（2）功能优先类目录规范；

什么是模块优先的目录规范？

如上图，以模块名为优先组织目录：

（1）根目录下，有das，entry，logic三个模块目录；

（2）在模块目录下，又分别有存放可执行文件，配置文件，日志文件的bin目录，conf目录，以及log目录；

 

什么是功能优先的目录规范？

如上图，以功能为优先组织目录：

（1）根目录下，二进制目录bin，配置文件目录conf，日志目录log；

（2）功能目录下，有das，entry，logic等不一样模块的目录；

 

楼主旗帜鲜明的推荐第二种，功能优先的目录规范，对二进制备份，配置备份，日志清理都很是方便。

 

有什么常见的日志规范呢？

日志规范化不但对日志监控，对大数据体系建设都极为重要，须要考虑规范：

（1）日志分级规范：不一样级别的日志理应打到不一样的文件中，例如FATAL级，ERROR级，WARM级，LOG级，INFO级，DEBUG级：

fatal.log

error.log

info.log

debug.log

…

（2）日志切分规范：运维应该提供自动化的日志切分工具，支持小时级别，或者天级别的日志切分，曾经看过一个120G的access日志，从日志中grep出某个uid的日志，是极其低效的：

daojia.log.2018012800

daojia.log.2018012801

…

daojia.log.2018012823

（3）日志格式规范：日志格式规范是一个可展开的话题，此处不展开；

画外音：是否是有小伙伴在思考，ca，本身怎么没有这三类规范呢？

 

通用可扩展日志监控框架，有什么思路？

制订了目录规范，日志规范以后，要创建日志监控框架，实施异常与正常的日志监控，就简单多了，主要有集中式监控，分散式监控两类思路。

 

什么是集中式日志监控？

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

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

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

（3）经过Kibana作统一分析和展示；

运维的同窗对这一套集中式日志监控系统很是熟悉。

 

什么是分散式日志监控？

ELK有点重，三套系统搭建与运维起来比较麻烦，若是只是为了实现ERROR日志的监控，异常关键字监控，正常关键字监控，有点杀鸡用牛刀了。

 

与集中式的日志监控相比，分散式的日志监控，就显得轻量级许多，很是适用与早期的创业型公司，其思路为：

（1）经过日志监控模块，对不一样集群，进行ERROR日志阈值设置，进行异常关键字设置，正常关键字设置；

（2）日志监控中心模块，进行统一调度，将配置分发到不一样机器的agent节点上；

（3）agent节点模块，并不统一收集日志，而是接收到监控中心分发的log监控配置，在各个机器上实施日志监控，若是触发日志监控策略，马上发起告警；

 

与ELK相比，这个日志监控框架会简单的多，并且扩展性很是好。

 

如何半天搞定日志监控框架？

整个框架设计如上，大体分为三个部分：

（1）被监控集群；

（2）基础信息与服务；

         cluster.info.xml：存储集群信息

         owner.info.xml：存储集群责任人信息

         mail.service/SM.service：告警基础服务

（3）日志监控框架；

 

集群信息与负责人信息，与前文描述的同样。

集群配置cluster.info.conf

[daojia_main]

ip.list : ip1, ip2, ip3

log.path : /home/work/log/daojia_main/

owner.list : shenjian, zhangsan

 

[daojia_user]

ip.list : ip4, ip5, ip6

log.path : /home/work/log/daojia_user/

owner.list : shenjian

 

责任人配置owner.info.conf

[shenjian]

email : XX@XX.com

phone :15912345678

 

[zhangsan]

email : YY@YY.com

phone :18611220099

 

日志监控框架又分为两个模块：

可扩展监控配置文件log.monitor.conf

[log.monitor.item]

cluster.name : daojia_main

# error日志监控，每分钟超过此阈值就告警

error.log. threshold : 10

# 异常关键字监控，日志出现这些关键字就告警

bad.key : exeption | timeout | coredump

# 正常关键字监控，日志每分钟不出现这些关键字就告警

good.key : login | user | click

 

[log.monitor.item]

cluster.name : daojia_user

error.log.threshold : 10

 

日志监控调度框架，这里须要编码啦，伪代码以下：

Array[log-monitor] A1= Parse(log.monitor.config);

Array[cluster-info] A2= Parse(cluster.info.config);

Array[owner-info] A3= Parse(owner.info.config);

 

// 遍历全部监控项

for(each item in A1){

         //取出监控项的集群名，阈值，异常/正常关键词

         clusterName= item.clusterName;

         threshold= item.threshold;

         badKey= item.badkey;

         goodKey= item.goodkey;

 

         //由集群名，获取集群信息

         clusterInfo= A2[clusterName];

         //获取日志目录，集群ip列表，集群负责人列表

         logPath= clusterInfo.path;

         List<String>ips = clusterInfo.ip;

         List<String>owners = clusterinfo.owner;

        

         //集群内的每个ip实例，都须要日志监控

         for(each ip in ips){

                   //登陆到这一台机器

                   ssh $ip

                   //跳到相关的目录下

                   cd $logPath

                   //查看近一分钟error日志数量

                   $count= `grep $time error.log | wc -l`

                   //查看badkey与goodkey

                   $boolBad= `grep $badkey *`

                   $boolGood= `grep $goodkey *`

 

                   if($count< threshold && 

                        $boolBad==NO &&

                         $boolGood==YES){

                            //正常，继续监控

                            continue;

                  }

 

                  // 不然，对全部集群负责人发送告警

                  for(each owner in owners){

                           // 略…

                  }

         }

}

 

一个简单的调度框架，看明白了吗？

架构师之路-分享技术思路

思路比结论更重要，但愿你们有收获。

调研

贵司的 日志 ，你的感 触是：

（1）ca，啥是日志，什么是grep，没有日志；

（2）日志不全，查问题的时候再加日志；

（3）日志全，但查问题的时候才上去grep一把；

（4）日志成体系，日志有监控，不须要grep；

本文分享自微信公众号 - 架构师之路（road5858）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。