作者：明明如月學長
鏈接：https://juejin.cn/post/7117046503616544804
一、背景
在日常開發中，通常為了方便除錯、方便查問題，會列印很多 INFO 級別的日志，
隨著訪問量越來越大，一不小心，某個日志檔案一天的 size 就大于了某個閾值（如 5G），于是，收到了優化日志大小的告警，一定時間內不優化反饋給你主管，囧...
日志過大容易導致一些運維操作消耗機器性能，如日志檔案檢索、資料采集、磁盤清理等，
那么，日志瘦身哪些常見的思路呢？ 本文結合某個具體案例談談我的看法，
推薦一個開源免費的 Spring Boot 最全教程：
https://github.com/javastacks/spring-boot-best-practice
二、日志瘦身方法論
2.1 只列印必要的日志
有時候為了方便測驗，臨時列印很多 INFO 級別日志，對于這種日志，等專案上線前，可以將非必要的日志洗掉或者調整為 DEBUG 級別，
但有些場景下有些日志可列印為 DEBUG 也可列印為 INFO，列印成 INFO 級別占空間，列印成 DEBUG 級別線上查問題的時候又需要用到，腫么辦？
我們可以對日志工具類進行改造，支持背景關系傳遞某個開關時（正常呼叫沒有這個開關，通過公司的 Tracer 或者 RPC背景關系傳遞），可以臨時將 DEBUG日志提升為 INFO級別， 偽代碼如下：
if(log.isDebugEnable()){
log.debug(xxx);
}else if(TracerUtils.openDebug2Info()){
log.info("【debug2info】"+xxx);
}
這樣，可以將一些糾結是否要列印成 INFO 日志的 log 列印成 DEBUG 級別，查問題時自動提升為INFO 日志， 為了避免誤會，區分 DEBUG 提升 INFO 的日志和普通 INFO 日志，加上 類似【debug2info】 日志前綴，
當然，你也可以搞一些其他騷操作，這里只是舉個例子，請自行舉一反三，
2.2 合并列印
有些可以合并的日志，可以考慮合并，
如在同一個方法前后都列印了 INFO 日志：
INFO [64 位traceId] XXXService 執行前 size =10 INFO [64 位traceId] XXXService 執行后 size =4
可以合并成一條：
INFO [64 位traceId] XXXService 執行前 size =10 執行后 size =4
2.3 簡化&縮寫&壓縮
某個日志非常有必要，但是列印的物件有些大，如果可以滿足問題排查需求的情況下，我們可以：
（1）選擇只列印其 ID
（2）創建一個只保留關鍵欄位的日志專用物件，轉化為日志專用物件，再列印，
（3）可以用縮寫，如 write 簡化為 w, read 簡化為 r, execute 簡化為e 等；比如 pipeline 中有 20個核心 bean ，列印日志時可以使用不同的編號替代 bean 全稱，如 S1,S2 ，雖然沒那么直觀，但既可以查問題，又降低了日志量，
三、優化案例
3.1 場景描述
一個業務場景涉及很多 bean， 為了復用一些通用邏輯，這些 bean 都繼承自某個抽象類， 在抽象類中，定義了執行 bean 前后的一些通用邏輯，如執行前后列印當前 pipeline 中 item 的數量， 最后一個 bean 執行完結果轉換后需要列印出結果，
3.2 優化分析
3.2.1 只列印必要日志
（1）由于當前 bean 執行前 相當于前一個 bean 執行后，因此只列印執行后的日志就可以，執行前的INFO 日志可以洗掉或者改為 DEBUG （只列印必要日志）
（2）通常問題只出現在執行前后 size 不一致的情況下，因此執行后列印日志前可以加個判斷，如果執行前后 size 相同則不列印，（只列印必要日志） 偽代碼如下：
if(sizeBefore != sizeAfter){
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
}
推薦一個開源免費的 Spring Boot 最全教程：
https://github.com/javastacks/spring-boot-best-practice
這招效果很明顯，因為大多數 bean 的執行前后 size 是相同的，就不會列印這條日志， 而假設之前有 20 個，這條日志就需要列印 20次，改進后可能只需要列印 2-3 次，
3.2.2 日志合并
（2）為了方便查問題還需要列印執行前的 size ，那么將執行前的 size 記錄在記憶體中，列印執行后日志時多列印出執行前的 size，（合并列印） 偽代碼如下：
log.info("service:{}, 執行前size:{}", getName(),sizeBefore)
log.info("service:{}, 執行后size:{}", getName(),sizeBefore, sizeAfter)
合并后
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
3.2.3 日志精簡
對于最終結果，將結果物件（如 XXDTO）轉化為只包括關鍵資訊，如 id, title 的日志物件（XXSimpleLogDTO），轉化為日志物件后再列印，
log.info("resultId:{}",result.getId());
或者
log.info("result:{}",toSimpleLog(result));
3.3 效果評估
該日志一天產生 5 G 左右，這里百分之80% 左右都是列印執行前后的 size，10%左右是列印最終結果, 還有一些其他的日志， 經過上述方法優化后，每天日志量不足 1G，
在滿足排查問題的需要，又實作日志瘦身之間進行了取舍，
四、總結
日志瘦身需要進行權衡，保留排查問題的必要日志情況下盡可能精簡，
可以采用洗掉不必要日志，合并日志，日志簡化等方式進行優化，
我們還可以進行一些騷操作，支持線上 DEBUG 臨時提升 INFO （當然也可以使用 arthas ）來輔助我們查問題，
你還有哪些不錯的日志瘦身技巧？ 歡迎在文章末尾評論和我交流，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/541641.html
標籤：其他
上一篇：檔案字串
下一篇：一次JVM GC長暫停的排查程序