由于日志配置复杂，很多同学喜欢直接cv其他项目或者网络博客的配置文件，而没有仔细研究每一个配置项。最常见的就是重复记录日志，这不仅给查看和统计带来不必要的麻烦，还会增加磁盘和日志采集系统的负担。下面我们来看几个常见的导致这个错误的案例，大家要引以为戒，以免被解雇。1logger配置继承错误图像定义方法记录四种日志：debug、info、warn、error：logback配置配置看起来没问题，但是执行该方法后明显重复记录：错误是因为AppenderCONSOLE是同时安装到两个记录器。definedand，因为defined继承自，相同的日志会通过logger记录并发送到rootrecord，所以应用包下的日志会重复。这样配置的初衷是什么？我想实现自定义记录器配置以临时启用应用程序内日志的DEBUG级别。其实不需要重复挂载Appender，把挂载的Appender去掉即可将应用程序日志输出到文件app.log其他框架日志输出到控制台。可设置的additivity属性为false，Appender2不会被继承。当LevelFilter配置为将错误记录到控制台时，日志会按级别记录到两个文件中。执行结果info.log文件包含INFO三级日志，WARN和ERROR，不符合预期有些公司使用自动化的ELK方案来收集日志，日志会同时输出到控制台和文件。开发者本地测试不关心文件中记录的日志，而在测试和生产环境中，由于开发者没有服务器访问权限，很难在原始日志文件中发现重复的问题。为什么会重复？ThresholdFilter源码分析图当日志级别≥配置级别时，返回NEUTRAL，继续调用过滤器链中的下一个过滤器，否则返回DENY，直接拒绝记录日志。本例中，我们将ThresholdFilter设置为WARN，这样WARN和ERROR就可以记录级别日志。LevelFilter用于比较日志级别，然后进行相应处理。如果匹配，则调用onMatch定义的处理方法：默认交给下一个filter处理（默认值定义在AbstractMatcherFilter基类中），否则调用onMismatch定义的处理方法：默认值也传递给下一个过滤器。与ThresholdFilter不同，LevelFilter只有Configuration级别并不能真正起作用。由于没有配置onMatch和onMismatch属性，过滤失败，导致INFO级别以上的日志全部被记录。修改配置LevelFilter的onMatch属性为ACCEPT，表示接收INFO级别的日志；将onMismatch属性设置为DENY，即除INFO级别外没有任何记录：所以，_info.log文件将只有INFO级别的日志，不会有日志重复。本文转载自微信公众号「JavaEdge」，可通过以下二维码关注。转载本文请联系JavaEdge公众号。
