【原】分布式架构下，关于业务日志我们应该这么做

　　

　　日志处理

　　背景

　　开发程序我们肯定会打印日志，原因在于，出了问题有迹可循，但是要做好日志也不是一件简单事，我们要考虑的问题有很多。

　　

　　日志级别

　　日志的级别

　　我们都知道日志有很多种级别，那么什么时候用什么级别，真的清楚吗？

　　普通的Info日志，出问题的Warning日志和Error日志、链路跟踪Trace日志、打印出参入参的Notice日志（也可是Access日志）。

　　同时我们也要了解，哪些日志我们需要持续的打印，哪些日志可以临时关闭，在需要的时候通过配置中心动态调整日志级别，打印该级别的日志。

　　

　　日志分割

　　日志的分割

　　日志过大，我们在排查分析的时候会过于繁琐，比如我们通过自带的命令在处理的时候，会出现占用大量系统资源，耗时比较常等问题。

　　日志分割的手段常见的有：日志框架自带的分割策略(log4j,logback等)，以及一些系统程序（如logrotate）。

　　

　　日志的收集

　　日志的收集

　　很多公司的业务已经进入分布式架构、微服务架构，那么这时候我们的日志是分散在不同的机器上的，我们不可能登录到每一台日志上查看记录是不是在其上，而是需要将日志集中收集起来，

　　然后在一个集中的地方进行查询，这种很多时候我们需要通过ELK（EFK）这种技术来实现日志的收集。

　　

　　日志平台

　　日志平台

　　收集上来日志后，我们需要一个平台进行查看，很多时候我们会将Kibana开放给大家进行搜索，查询，但是我们需要防止其查询语法不对，导致我们程序宕机，更大的问题可能是并不是所有人都会使用

　　Lucene语法，我们要提供一个日志搜索平台（大家点点下拉菜单，输入一下简单要搜索的内容就可以给出结果日志），这样才可以算是一个良好的方案。

　　

　　日志备份

　　日志的备份

　　日志量如果过大，我们不可能在ElasticSearch中保存太长时间的日志数据，所以我们需要将历史的一些日志进行备份，需要的时候将其加载到ElasticSearch里，提供日志搜索。