前言
關於日志，在大家的印象中都是比較簡單的，只須引入了相關依賴包，剩下的事情就是在項目中“盡情”的打印我們需要的信息了。但是往往越簡單的東西越容易讓我們忽視，從而導致一些不該有的bug發生，作為一名嚴謹的程序員，怎么能讓這種事情發生呢？所以下面我們就來了解一下關於日志的那些正確使用姿勢。
正文
日志規范
命名
首先是日志文件的命名，盡量要做到見名知意，團隊里面也必須使用統一的命名規范，不然“臟亂差”的日志文件會影響大家排查問題的效率。這里推薦以“projectName_logName_logType.log”來命名，這樣通過名字就可以清晰的知道該日志文件是屬於哪個項目，什么類型，有什么作用。例如在我們MessageServer項目中監控Rabbitmq 消費者相關的日志文件名可以定義成“messageserver_rabbitmqconsumer_monitor.log”。
保存時間
關於日志保存的時間，普通的日志文件建議保留15天，若比較重要的可根據實際情況延長，具體請參考各自服務器磁盤空間以及日志文件大小作出最優選擇。
日志級別
常見的日志級別有以下：
-
DEBUG級別:記錄調試程序相關的信息。
-
INFO級別:記錄程序正常運行有意義的信息。
-
WARN級別:記錄可能會出現潛在錯誤的信息。
-
ERROR級別:記錄當前程序出錯的信息，需要被關注處理。
-
Fatal級別：表示出現了嚴重錯誤，程序將會中斷執行。
建議在項目中使用這四種級別， ERROR、WARN、INFO 、DEBUG。
正確姿勢
1、提前判斷日志級別
//條件判斷 if(logger.isDebugEnabled){ logger.debug("server info , id : " + id + ", user : " + user); } //使用占位符 logger.debug("server info , id : {}, user : {}",id,user);
對於DEBUG,INFO級別的日志，在我們的程序中是比較高頻的存在，當我們的項目大了，日志變多了，這時候為了程序運行的效率，我們必須以條件判斷或者占位符的方式來打印日志。為什么呢？假如我們項目中配置的日志級別為WARN,那么對於我們下面的日志輸出語句‘ logger.debug("server info , id : " + id + ", user : " + user);’，雖然該日志不會被打印，但是卻會執行字符串拼接的操作，這里我們的user是一個實例對象，所以還會執行toString方法，這樣就白白浪費了不少系統的資源。
2、避免多余日志輸出
在我們的生產環境中，一般禁止DEBUG日志的輸出，其打印的頻率是非常高的，容易對正常運行的程序造成嚴重的影響，在我們最近的項目中就有遇到過類似的情況。
那么這時候該學會使用additivity屬性
<logger name="xx" additivity="true">
在這邊配置成true的話，也就是默認的情況，這時候當前Logger會繼承父Logger的Appender，說白了就是當前日志的輸出除了輸出在當前日志文件以外，還會輸出至父文件里。所以一般情況下，我們為了避免重復打印，會將這個參數設置成false，以減少不必要的輸出。
3、保證日志記錄信息完整
在我們的代碼中，日志記錄的內容要包含異常的堆棧，請勿隨意輸出“XX出錯”等簡單的日志，這對於錯誤的調試毫無幫助。所以我們在記錄異常的時候一定要帶上堆棧信息，例如
logger.error("rabbitmq consumer error,cause : "+e.getMessage(),e);
切記在輸出對象實例的時候，須確保對象重寫了toString方法，否則只會輸出其hashCode值。
4、定義logger變量為static
private static final Logger logger = LoggerFactory.getLogger(XX.class);
確保一個對象只使用一個Logger對象，避免每次都重新創建，否則可能會導致OOM。
5、正確使用日志級別
try{ //.. }catch(xx){ logger.info(..); }
這樣一來，本來是ERROR的信息，全都打印在INFO日志文件里了，不知情的同事還會在死盯着錯誤日志，而且還找不出問題，多影響工作效率是吧?
6、推薦使用slf4j+logback組合
logback庫里自身就已經實現了slf4j的接口，就無需引入多余的適配器了，而且logback也具有更多的優點，建議新項目可以使用這個組合。還有一點需要注意，當引入slf4j后，要注意其實際使用的日志庫是否是由我們引入的，也有可能會使用了我們第三方依賴包所帶入的日志庫，這樣就可能會導致我們的日志失效。
7、日志的聚合分析
日志的聚合可以把位於不同服務器之間的日志統一起來分析處理，如今ELK技術棧亦或者的EFG（fluentd+elasticsearch+grafana）等都是一些比較成熟的開源解決方案。
拿ELK來說，可以在我們的服務器上直接通過logstash來讀取應用打印的日志文件，或者也可以在我們項目中的日志配置文件里配置好相關的socket信息，打印的時候直接把日志信息輸出至logstash。再交由elasticsearch存儲，kibana展示。
結語
好了，關於日志先聊這么多~ 大家有需要補充或者交流的可以在下方留言哦。
------------------------------------------------------
【推薦閱讀】
看完本文有收獲？請轉發分享給朋友吧
關注「深夜里的程序猿」，分享最干的干貨
