建站
咨詢
售后
建站咨詢
新聞中心
一、背景
在日常開發(fā)中，通常為了方便調(diào)試、方便查問題，會打印很多 INFO 級別的日志。
創(chuàng)新互聯(lián)長期為超過千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為烏翠企業(yè)提供專業(yè)的成都網(wǎng)站設計、成都網(wǎng)站制作，烏翠網(wǎng)站改版等技術(shù)服務。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
隨著訪問量越來越大，一不小心，某個日志文件一天的 size 就大于了某個閾值（如 5G），于是，收到了優(yōu)化日志大小的告警，一定時間內(nèi)不優(yōu)化反饋給你主管，囧...
日志過大容易導致一些運維操作消耗機器性能，如日志文件檢索、數(shù)據(jù)采集、磁盤清理等。
那么，日志瘦身哪些常見的思路呢？本文結(jié)合某個具體案例談談我的看法。
二、日志瘦身方法論
?
?1、只打印必要的日志
有時候為了方便測試，臨時打印很多 INFO 級別日志。對于這種日志，等項目上線前，可以將非必要的日志刪除或者調(diào)整為 DEBUG 級別。
但有些場景下有些日志可打印為 DEBUG 也可打印為 INFO，打印成 INFO 級別占空間，打印成 DEBUG 級別線上查問題的時候又需要用到，腫么辦？
我們可以對日志工具類進行改造，支持上下文傳遞某個開關(guān)時（正常調(diào)用沒有這個開關(guān)，通過公司的 Tracer 或者 RPC上下文傳遞），可以臨時將 DEBUG日志提升為 INFO級別。偽代碼如下：
if(log.isDebugEnable()){
log.debug(xxx);
}else if(TracerUtils.openDebug2Info()){
log.info("【debug2info】"+xxx);
}這樣，可以將一些糾結(jié)是否要打印成 INFO 日志的 log 打印成 DEBUG 級別，查問題時自動提升為INFO 日志。為了避免誤會，區(qū)分 DEBUG 提升 INFO 的日志和普通 INFO 日志，加上 類似【debug2info】 日志前綴。
當然，你也可以搞一些其他騷操作，這里只是舉個例子，請自行舉一反三。
2、合并打印
有些可以合并的日志，可以考慮合并。
如在同一個方法前后都打印了 INFO 日志：
INFO [64 位traceId] XXXService 執(zhí)行前 size =10 INFO [64 位traceId] XXXService 執(zhí)行后 size =4
可以合并成一條：
INFO [64 位traceId] XXXService 執(zhí)行前 size =10 執(zhí)行后 size =4
3、簡化&縮寫&壓縮
某個日志非常有必要，但是打印的對象有些大，如果可以滿足問題排查需求的情況下，我們可以：
選擇只打印其 ID。
創(chuàng)建一個只保留關(guān)鍵字段的日志專用對象，轉(zhuǎn)化為日志專用對象，再打印。
可以用縮寫，如 write 簡化為 w, read 簡化為 r, execute 簡化為e 等；比如 pipeline 中有 20個核心 bean ，打印日志時可以使用不同的編號替代 bean 全稱，如 S1,S2 ，雖然沒那么直觀，但既可以查問題，又降低了日志量。
三、優(yōu)化案例
1、場景描述
一個業(yè)務場景涉及很多 bean， 為了復用一些通用邏輯，這些 bean 都繼承自某個抽象類。
在抽象類中，定義了執(zhí)行 bean 前后的一些通用邏輯，如執(zhí)行前后打印當前 pipeline 中 item 的數(shù)量。最后一個 bean 執(zhí)行完結(jié)果轉(zhuǎn)換后需要打印出結(jié)果。
2、優(yōu)化分析
1）只打印必要日志
由于當前 bean 執(zhí)行前 相當于前一個 bean 執(zhí)行后，因此只打印執(zhí)行后的日志就可以，執(zhí)行前的INFO 日志可以刪除或者改為 DEBUG （只打印必要日志）
通常問題只出現(xiàn)在執(zhí)行前后 size 不一致的情況下，因此執(zhí)行后打印日志前可以加個判斷，如果執(zhí)行前后 size 相同則不打印。（只打印必要日志） 偽代碼如下：
if(sizeBefore != sizeAfter){
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
}
這招效果很明顯，因為大多數(shù) bean 的執(zhí)行前后 size 是相同的，就不會打印這條日志。而假設之前有 20 個，這條日志就需要打印 20次，改進后可能只需要打印 2-3 次。
2）日志合并
為了方便查問題還需要打印執(zhí)行前的 size ，那么將執(zhí)行前的 size 記錄在內(nèi)存中，打印執(zhí)行后日志時多打印出執(zhí)行前的 size。（合并打?。?偽代碼如下：
log.info("service:{}, 執(zhí)行前size:{}", getName(),sizeBefore)
log.info("service:{}, 執(zhí)行后size:{}", getName(),sizeBefore, sizeAfter)合并后：
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)3）日志精簡
對于最終結(jié)果，將結(jié)果對象（如 XXDTO）轉(zhuǎn)化為只包括關(guān)鍵信息，如 id, title 的日志對象（XXSimpleLogDTO），轉(zhuǎn)化為日志對象后再打印。
log.info("resultId:{}",result.getId());或者
log.info("result:{}",toSimpleLog(result));3、效果評估
該日志一天產(chǎn)生 5 G 左右，這里百分之80% 左右都是打印執(zhí)行前后的 size，10%左右是打印最終結(jié)果, 還有一些其他的日志。
經(jīng)過上述方法優(yōu)化后，每天日志量不足 1G。
在滿足排查問題的需要，又實現(xiàn)日志瘦身之間進行了取舍。
四、總結(jié)
日志瘦身需要進行權(quán)衡，保留排查問題的必要日志情況下盡可能精簡。
可以采用刪除不必要日志，合并日志，日志簡化等方式進行優(yōu)化。
我們還可以進行一些騷操作，支持線上 DEBUG 臨時提升 INFO （當然也可以使用 arthas ）來輔助我們查問題。
分享標題：5G變1G，線上日志瘦身還有這些騷操作
轉(zhuǎn)載注明：http://fisionsoft.com.cn/article/djcsspd.html
