5G變1G，線上日志瘦身還有這些騷操作
一、背景
在日常開發中，通常為了方便調試、方便查問題，會打印很多 INFO 級別的日志。
隨著訪問量越來越大，一不小心，某個日志文件一天的 size 就大于了某個閾值（如 5G），于是，收到了優化日志大小的告警，一定時間內不優化反饋給你主管，囧...
日志過大容易導致一些運維操作消耗機器性能，如日志文件檢索、數據采集、磁盤清理等。
那么，日志瘦身哪些常見的思路呢？本文結合某個具體案例談談我的看法。
二、日志瘦身方法論
?
?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、合并打印
有些可以合并的日志，可以考慮合并。
如在同一個方法前后都打印了 INFO 日志：
INFO [64 位traceId] XXXService 執行前 size =10 INFO [64 位traceId] XXXService 執行后 size =4
可以合并成一條：
INFO [64 位traceId] XXXService 執行前 size =10 執行后 size =4
3、簡化&縮寫&壓縮
某個日志非常有必要，但是打印的對象有些大，如果可以滿足問題排查需求的情況下，我們可以：
選擇只打印其 ID。
創建一個只保留關鍵字段的日志專用對象，轉化為日志專用對象，再打印。
可以用縮寫，如 write 簡化為 w, read 簡化為 r, execute 簡化為e 等；比如 pipeline 中有 20個核心 bean ，打印日志時可以使用不同的編號替代 bean 全稱，如 S1,S2 ，雖然沒那么直觀，但既可以查問題，又降低了日志量。
三、優化案例
1、場景描述
一個業務場景涉及很多 bean， 為了復用一些通用邏輯，這些 bean 都繼承自某個抽象類。
在抽象類中，定義了執行 bean 前后的一些通用邏輯，如執行前后打印當前 pipeline 中 item 的數量。最后一個 bean 執行完結果轉換后需要打印出結果。
2、優化分析
1）只打印必要日志
由于當前 bean 執行前 相當于前一個 bean 執行后，因此只打印執行后的日志就可以，執行前的INFO 日志可以刪除或者改為 DEBUG （只打印必要日志）
通常問題只出現在執行前后 size 不一致的情況下，因此執行后打印日志前可以加個判斷，如果執行前后 size 相同則不打印。（只打印必要日志） 偽代碼如下：
if(sizeBefore != sizeAfter){
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
}
這招效果很明顯，因為大多數 bean 的執行前后 size 是相同的，就不會打印這條日志。而假設之前有 20 個，這條日志就需要打印 20次，改進后可能只需要打印 2-3 次。
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）日志精簡
對于最終結果，將結果對象（如 XXDTO）轉化為只包括關鍵信息，如 id, title 的日志對象（XXSimpleLogDTO），轉化為日志對象后再打印。
log.info("resultId:{}",result.getId());
或者
log.info("result:{}",toSimpleLog(result));
3、效果評估
該日志一天產生 5 G 左右，這里百分之80% 左右都是打印執行前后的 size，10%左右是打印最終結果, 還有一些其他的日志。
經過上述方法優化后，每天日志量不足 1G。
在滿足排查問題的需要，又實現日志瘦身之間進行了取舍。
四、總結
日志瘦身需要進行權衡，保留排查問題的必要日志情況下盡可能精簡。
可以采用刪除不必要日志，合并日志，日志簡化等方式進行優化。
我們還可以進行一些騷操作，支持線上 DEBUG 臨時提升 INFO （當然也可以使用 arthas ）來輔助我們查問題。
