別在 Java 代碼裏亂打日誌了，這纔是正確的打日誌姿勢！
使用slf4j
-
使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式統一。
-
實現方式統一使用: Logback框架
打日誌的正確方式
什麼時候應該打日誌
-
當你遇到問題的時候，只能通過debug功能來確定問題，你應該考慮打日誌，良好的系統，是可以通過日誌進行問題定爲的。
-
當你碰到if…else 或者 switch這樣的分支時，要在分支的首行打印日誌，用來確定進入了哪個分支
-
經常以功能爲核心進行開發，你應該在提交代碼前，可以確定通過日誌可以看到整個流程
基本格式
必須使用參數化信息的方式:
logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);
對於debug日誌，必須判斷是否爲debug級別後，才進行使用:
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " +id + " symbol: " + symbol);
}
不要進行字符串拼接,那樣會產生很多String對象，佔用空間，影響性能。
反例(不要這麼做):
logger.debug("Processing trade with id: " + id + " symbol: " + symbol);
使用[]進行參數變量隔離
如有參數變量，應該寫成如下寫法:
logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);
這樣的格式寫法，可讀性更好，對於排查問題更有幫助。
不同級別的使用
ERROR:
基本概念
影響到程序正常運行、當前請求正常運行的異常情況:
-
打開配置文件失敗
-
所有第三方對接的異常(包括第三方返回錯誤碼)
-
所有影響功能使用的異常，包括:SQLException和除了業務異常之外的所有異常(RuntimeException和Exception)
不應該出現的情況:
-
比如要使用Azure傳圖片，但是Azure未響應
如果有Throwable信息，需要記錄完成的堆棧信息:
log.error("獲取用戶[{}]的用戶信息時出錯",userName,e);
說明
-
如果進行了拋出異常操作，請不要記錄error日誌，由最終處理方進行處理：
反例(不要這麼做):
try{
....
}catch(Exception ex){
String errorMessage=String.format("Error while reading information of user [%s]",userName);
logger.error(errorMessage,ex);
throw new UserServiceException(errorMessage,ex);
}
WARN
基本概念
不應該出現但是不影響程序、當前請求正常運行的異常情況:
-
有容錯機制的時候出現的錯誤情況
-
找不到配置文件，但是系統能自動創建配置文件
即將接近臨界值的時候，例如：
-
緩存池佔用達到警告線
業務異常的記錄,比如:
-
當接口拋出業務異常時，應該記錄此異常
INFO:
基本概念
系統運行信息
-
Service方法中對於系統/業務狀態的變更
-
主要邏輯中的分步驟
外部接口部分
-
客戶端請求參數(REST/WS)
-
調用第三方時的調用參數和調用結果
說明
-
並不是所有的service都進行出入口打點記錄,單一、簡單service是沒有意義的(job除外,job需要記錄開始和結束,)。
反例(不要這麼做):
public List listByBaseType(Integer baseTypeId) {
log.info("開始查詢基地");
BaseExample ex=new BaseExample();
BaseExample.Criteria ctr = ex.createCriteria();
ctr.andIsDeleteEqualTo(IsDelete.USE.getValue());
Optionals.doIfPresent(baseTypeId, ctr::andBaseTypeIdEqualTo);
log.info("查詢基地結束");
return baseRepository.selectByExample(ex);
} -
對於複雜的業務邏輯，需要進行日誌打點，以及埋點記錄，比如電商系統中的下訂單邏輯，以及OrderAction操作(業務狀態變更)。
-
對於整個系統的提供出的接口(REST/WS)，使用info記錄入參
-
如果所有的service爲SOA架構，那麼可以看成是一個外部接口提供方，那麼必須記錄入參。
-
調用其他第三方服務時，所有的出參和入參是必須要記錄的(因爲你很難追溯第三方模塊發生的問題)
DEBUG
基本概念
-
可以填寫所有的想知道的相關信息(但不代表可以隨便寫，debug信息要有意義,最好有相關參數)
-
生產環境需要關閉DEBUG信息
-
如果在生產情況下需要開啓DEBUG,需要使用開關進行管理，不能一直開啓。
說明
如果代碼中出現以下代碼，可以進行優化:
//1. 獲取用戶基本薪資
//2. 獲取用戶休假情況
//3. 計算用戶應得薪資
優化後的代碼:
logger.debug("開始獲取員工[{}] [{}]年基本薪資",employee,year);
logger.debug("獲取員工[{}] [{}]年的基本薪資爲[{}]",employee,year,basicSalary);
logger.debug("開始獲取員工[{}] [{}]年[{}]月休假情況",employee,year,month);
logger.debug("員工[{}][{}]年[{}]月年假/病假/事假爲[{}]/[{}]/[{}]",employee,year,month,annualLeaveDays,sickLeaveDays,noPayLeaveDays);
logger.debug("開始計算員工[{}][{}]年[{}]月應得薪資",employee,year,month);
logger.debug("員工[{}] [{}]年[{}]月應得薪資爲[{}]",employee,year,month,actualSalary);
TRACE
基本概念
特別詳細的系統運行完成信息，業務代碼中，不要使用.(除非有特殊用意，否則請使用DEBUG級別替代)
規範示例說明
@Override
@Transactional
public void createUserAndBindMobile(@NotBlank String mobile, @NotNull User user) throws CreateConflictException{
boolean debug = log.isDebugEnabled();
if(debug){
log.debug("開始創建用戶並綁定手機號. args[mobile=[{}],user=[{}]]", mobile, LogObjects.toString(user));
}
try {
user.setCreateTime(new Date());
user.setUpdateTime(new Date());
userRepository.insertSelective(user);
if(debug){
log.debug("創建用戶信息成功. insertedUser=[{}]",LogObjects.toString(user));
}
UserMobileRelationship relationship = new UserMobileRelationship();
relationship.setMobile(mobile);
relationship.setOpenId(user.getOpenId());
relationship.setCreateTime(new Date());
relationship.setUpdateTime(new Date());
userMobileRelationshipRepository.insertOnDuplicateKey(relationship);
if(debug){
log.debug("綁定手機成功. relationship=[{}]",LogObjects.toString(relationship));
}
log.info("創建用戶並綁定手機號. userId=[{}],openId=[{}],mobile=[{}]",user.getId(),user.getOpenId(),mobile); // 如果考慮安全，手機號記得脫敏
}catch(DuplicateKeyException e){
log.info("創建用戶並綁定手機號失敗,已存在相同的用戶. openId=[{}],mobile=[{}]",user.getOpenId(),mobile);
throw new CreateConflictException("創建用戶發生衝突, openid=[%s]",user.getOpenId());
}
}
