关于logback的一个坑：日志级别设置无效

目录

起因及现象

排查过程

---

大晚上的分享一个坑，logback设置的日志级别无效的问题，也是刚刚出现的

起因及现象

起因是我们的系统上个月进行了一次数据迁移与防渗透加密，在上线后，最近我们发现一部分数据没有成功加密，可能是因为加密程序有问题，也可能是因为加密的数据有问题，于是大家就去找日志，但是加密程序打印的加密过程都是DEBUG级别的日志，而线上服务都是INFO级别（加密程序写成了依赖包，由使用的程序引入，所以其日志也依赖于归属服务一起打印），于是，就将logback的级别调整成了DEBUG，再进行测试

但是，调整完成后，相关的人员发现没有生效

排查过程

首先，大家有这么几个怀疑

• logback的配置错了
• 加密程序没有打印日志
• logback的配置没有生效

于是，大家挨个排查

第一个，大家在测试环境试了试，发现相同的配置是生效的，也因为这个测试，第二点直接就证明了没问题了

于是，就剩下了最后一个，logback为何没有生效

在这个时候，大家还是认为是logback的配置有问题，于是又上网找了好些个配置，发现都是没什么大区别

于是都相当恼火啊，为什么不生效，没有头绪，当然，也包括楼主，虽然楼主不用logback，但是也用过，也想不到丝毫问题

正巧这个时候，我看到群里测试在说其他问题（比较苦逼，周末晚上还在加班），在说谁把测试环境关键服务的日志级别调整成DEBUG了，满屏都是日志，他们找不到自己发的请求日志了，然后还把rc的记录贴出来了，说昨天还是INFO

哦吼，也就是这个时候灵感来了，是不是加密程序自己配置了日志级别，导致了logback的生效了，但是是被覆盖掉了

于是，大家直接翻加密程序的源码，发现它有一些默认配置，而在application.yml里，有一项配置：logging.level，全都配置成了INFO

在删除了这一项，重新进行测试，发现没问题了，罪魁祸首就是这一项配置！

OK，日志问题解决，剩下的就是其他问题了