日志监控，是每个公司必须解决的一个问题。创业型公司，如何用半天的时间，搞定一个可扩展，通用的日志监控框架，是今天要聊的话题。
什么是日志监控？
关于日志，不同公司，情况不同：
（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){
// 略…
}
}
}
一个简单的调度框架，看明白了吗？
