Java日誌正確使用姿勢

深夜裡的程式猿發表於2019-04-22
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展示。

結語

好了，關於日誌先聊這麼多~ 大家有需要補充或者交流的可以在下方留言哦。

推薦閱讀

《使用ConcurrentHashMap一定執行緒安全？》
《大白話搞懂什麼是同步/非同步/阻塞/非阻塞》
《論JVM爆炸的幾種姿勢及自救方法》
《解放程式設計師雙手之Supervisor》

有收穫的話，就點個贊吧

關注「深夜裡的程式猿」，分享最乾的乾貨

Java日誌正確使用姿勢

相關文章