2.2日誌規約

1.強制：應用中不可直接使用日誌系統（log4j、logback）中的 API ，而應依賴使用日誌框架 SLF4J 中的 API 。使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式的統一。

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import satic final Logger logger = LoggerFactory.getLogger(Abc.class);

2.強制：日誌文件推薦至少保存 15 天，因爲有些異常具備以 “周”爲頻次發生的特點。

3.強制：應用中的擴展日誌（如打點、臨時監控、訪問日誌等）命名方式： appName_LogType_LogName.log。logType 爲日誌類型，推薦分類有 stats / monitor / visit 等；LogName 爲日誌描述。這種命名的好處：通過文件名就可以知道日誌文件屬於哪種應用，哪種類型，有什麼目的，這也有利於歸類查找。

正例：

        在 mppserver 應用中單獨監控時區轉換異常，如：

        mappserver_monitor_timmZoneConvert.log

推薦：

        推薦對日誌進行分類，如將錯誤日誌和業務日誌分開存放，既便於開發人員查看，也便於通過日誌對系統進行及時監控。

4.強制：對 trance / debug / info 級別的日誌輸出，必須使用條件輸出形式或者佔位符的方式。

說明：

        Logger.debug("Processing trade with id:" + id + " and symbol: " + symbol )；，如果日誌級別是 warn ，如果 symbol 是對象，會執行 toString() 方法，浪費了系統資源，執行了上述操作，最終日誌卻沒有被打印。

正例：（條件）

if(logger.isDebugEnabled){

        logger.debug("Processing trade with id:"+ id +" and symbol : " + symbol );

}

正例：（佔位符）

logger.debug("Processing trade with id: {} and symbol ： {} “,id , symbol );

5.強制：避免重複打印日誌，否則會浪費磁盤空間。務必在日誌配置文件中設置 additivity = false。

正例：

        <logger name = "com.taobao.dubbo.config" additivity ="false">

6.強制：異常信息應該包括兩類：案發現場信息和異常堆棧信息。如果不處理，那麼通過關鍵字 throws 往上拋出。

正例：

        logger.error(各類參數或者對象 toString + "_" + e.getMessage() , e);

7.推薦：謹慎的記錄日誌。生產環境禁止輸出 debug 日誌；有選擇的輸出 info 日誌；如果使用 warn 記錄剛上線時的業務行爲信息，一定要注意日誌輸出量的問題，避免把服務器磁盤撐爆，並及時刪除這些觀察日誌。

說明：大量的輸出無效日誌，既不利於提升系統性能，也不利於快速定位錯誤點。記錄日誌時請思考：這些日誌真的有人看嗎？看到這條日誌你能做什麼？能不能給問題排查帶來好處？

8.推薦：可以使用 warn 日誌級別記錄用戶輸入參數錯誤的情況，避免當用戶投訴時無所適從。

說明：

        如非必要，請不要在此場景中打出 error 級別。注意日誌輸出的級別，error 級別只記錄系統邏輯出錯、異常等重要的錯誤信息。