Java日誌正確使用姿勢

前言

關於日誌,在大家的印象中都是比較簡單的,只須引入了相關依賴包,剩下的事情就是在項目中“盡情”的打印我們需要的信息了。但是往往越簡單的東西越容易讓我們忽視,從而導致一些不該有的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展示。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章