DEBUG技巧-设定合适的日志级别

---

有些技能只有踩过坑的人才能够掌握,能用来避免后来的坑,很多时候是用凌晨的时间换来的，我们通常把他叫做经验。

故事

这个一个关于springmvc的坑的故事。

某天晚上本打算一个小功能分分钟搞定上线,但页面总是报404错误,肉眼实在找不到原因。
各种手段折腾,断点,重启,重新打包,拍脑袋觉得代码没写错,url路径也ok,真心没问题，无数次f5就是不出来。

很多时候遇到一个bug越着急越搞不定，我就是这种情况，花了一两个小时时间，眼看都过0点了，此时我正用最后的手段，引入spring源码直接一步步debug，看起来也没问题，那能不能更深入点，从spring启动开始。

这时我突然想到了日志，平时线上的日志级别都是error，本地一般也很少改，大多数情况都是断点debug，日志更多的是用来日后线上问题排查。所以我改了下spring的日志级别，看看他启动干了啥。

因此，修改了下log4j的配置文件，将springmvc的日志级别改为debug，如果是logback的话，配置文件也是类似。

<logger name="org.springframework.web">
<level value="DEBUG"/>
</logger>

这样的话启动后，springmvc就会打印出它所加载的路径映射，每次请求也会详细打印出请求的参数，路径等等。

然后，重启，看到控制台打印出来的路径和我实际访问的路径，问题一目了然了，原来我与显示页面只差一个字母大小写的距离。看一下时间，已然是凌晨1点，默默的在心里说一句：WTF。然后倒头就睡。

---

合理的日志级别

日志是我们经常用到的东西,但很多时候只有在遇到线上bug之类的情况才会想起有日志可以协助排查,但开发的时候一点点日志级别修改,就能避免某个bug调试到凌晨1点才发现与答案只差一个字母的距离。

我个人的经验，在web项目时会把三个方面的日志级别改为debug

1. webmvc框架：springmvc 或者struts2，主要查看请求路径和参数，页面400，404了，看看请求路径和参数对不对；
2. orm框架：如mybatis，debug级别会打印sql和参数，有sql异常通过日志就可以很快定位；
3. 项目本身的业务日志，这个一般很少。

至于其他外部依赖的项目根据需要自行定义，root日志级别一般是error，不然很多其他日志混进来会导致很难查看。

对于struts2，日志级别是这么定义的。

<logger name="com.opensymphony.xwork2">
<level value="DEBUG"/>
</logger>

当然这是xml格式的配置文件，如果是properties，需要这么做

log4j.logger.com.opensymphony.xwork2=debug

mybatis的sql则可参考如下

log4j.logger.com.ibatis=debug
log4j.logger.java.sql.Connection=debug
log4j.logger.java.sql.PreparedStatement=debug

---

本文于2016-07-07 18:32:58从Chu Lung's blog自动同步同步,访问原文