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自動同步同步,訪問原文

DEBUG技巧-設定合適的記錄層級