Log In Action

Log In Action

0. 生產環境要關閉debug日誌，嚴禁在生產環境打debug級別日誌

1. trace/debug/info 日誌輸出採用佔位符的方式，禁止使用字符串拼接的方式

說明：logger.debug("=====" + b)，若是當前的日誌級別是warn，上述日誌不會打印，但會執行字符串拼接操做，若是b是對象，會調用b的toString()方法，這樣會很是浪費系統資源，特別是當b是個大對象的時候。

bad case:

log.info("finish import seller " + sellerId)

# 有現成的佔位符的方式，不要使用String.format()，代碼複雜
log.info(String.format("group_id=%s",groupId))

good case:

logger.info("modify audit status, noteId: [{}], creativityId: [{}]", noteId, creativity.getId());

我的也不推薦條件輸出形式，用這種if的方式判斷，顯然不夠優雅

if (logger.isDebugEnabled()) {
    logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
}

2. 使用[]進行參數變量隔離

這樣的格式寫法，可讀性更好，對於排查問題又幫助。

good case:

logger.info("modify audit status, noteId: [{}], creativityId: [{}]", noteId, creativity.getId())

3. 使用warn級別日誌記錄用戶輸入參數錯誤的狀況，不要使用error級別日誌記錄此類錯誤，避免頻繁報警

bad case:

log.error("Porch: 建立帳號失敗：傳入參數有誤：email={}, name={}", email, name)

good case:

logger.warn("建立單元名稱重複，unit_name={}", req.getUnitName())

4. 異常信息應該包含兩類信息：案發現場和異常堆棧信息

bad case:

log.error("調用sellerCenter服務異常")

good case:

logger.error("RPC調用[inventory.multi_get_available]失敗", e);

若是拋出異常，不要記錄error日誌，由上層進行處理

若是既打錯誤日誌，又拋出異常，會致使錯誤日誌的重複打印。

bad case:

try {
     ...   
    } catch (TException e) {
        logger.error("RPC調用[item_center.multi_get_item_union]失敗", e);
        throw new BaseException(ResponseCode.ITEM_SYSTEM_ERROR);
    }

good case:

try {
     ...   
    } catch (TException e) {
        // e必須傳遞給從新拋出的異常，不然會致使異常棧的丟失
        throw new BaseException("xxxx", e);
    }

logback VS log4j2 性能對比

linux:
8核 2.4Hz
32G 內存

50個線程，每一個線程寫2W行日誌

logback:
100W行日誌總計耗時:7419 ms
100W行日誌總計耗時:7337 ms
100W行日誌總計耗時:7345 ms
100W行日誌總計耗時:7263 ms
100W行日誌總計耗時:7084 ms

log4j2:
100W行日誌總計耗時:3815 ms
100W行日誌總計耗時:3904 ms
100W行日誌總計耗時:3743 ms
100W行日誌總計耗時:3766 ms
100W行日誌總計耗時:3755 ms

總結

將來是log4j2的。

原文連接

https://segmentfault.com/a/11...