使用slf4j
使用門面模式的日志架構,有利于維護和各個類的日志處理方式統一。
實作方式統一使用: Logback架構
打日志的正确方式
什麼時候應該打日志
當你遇到問題的時候,隻能通過debug功能來确定問題,你應該考慮打日志,良好的系統,是可以通過日志進行問題定為的。
當你碰到if…else 或者 switch這樣的分支時,要在分支的首行列印日志,用來确定進入了哪個分支
經常以功能為核心進行開發,你應該在送出代碼前,可以确定通過日志可以看到整個流程
1.fatal - 嚴重的,造成服務中斷的錯誤;
2.error - 其他錯誤運作期錯誤;
3.warn - 警告資訊,如程式調用了一個即将廢棄的接口,接口的不當使用,運作狀态不是期望的但仍可繼續處理等;
4.info - 有意義的事件資訊,如程式啟動,關閉事件,收到請求事件等;
5.debug - 調試資訊,可記錄詳細的業務處理到哪一步了,以及目前的變量狀态;
6.trace - 更詳細的跟蹤資訊;
基本格式
必須使用參數化資訊的方式:
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());
}
}
基本的Logger編碼規範
1.在一個對象中通常隻使用一個Logger對象,Logger應該是static final的,隻有在少數需要在構造函數中傳遞logger的情況下才使用private final。
image
2.輸出Exceptions的全部Throwable資訊,因為logger.error(msg)和logger.error(msg,e.getMessage())這樣的日志輸出方法會丢失掉最重要的StackTrace資訊。
3.不允許記錄日志後又抛出異常,因為這樣會多次記錄日志,隻允許記錄一次日志。
4.不允許出現System print(包括System.out.println和System.error.println)語句。
5.不允許出現printStackTrace。
6.日志性能的考慮,如果代碼為核心代碼,執行頻率非常高,則輸出日志建議增加判斷,尤其是低級别的輸出<debug、info、warn>。
debug日志太多後可能會影響性能,有一種改進方法是:
但更好的方法是Slf4j提供的
最佳實踐:
一方面可以減少參數構造的開銷,另一方面也不用多寫兩行代碼。
7.有意義的日志
通常情況下在程式日志裡記錄一些比較有意義的狀态資料:程式啟動,退出的時間點;程式運作消耗時間;耗時程式的執行進度;重要變量的狀态變化。
初次之外,在公共的日志裡規避列印程式的調試或者提示資訊。