1、日誌的級別一定要搞清楚
ERROR
ERROR是最高級別錯誤，反映系統發生了非常嚴重的故障，無法自動恢復到正常態工作，需要人工介入處理。系統需要將錯誤相關痕跡以及錯誤細節記錄ERROR日誌中，方便後續人工回溯解決。
WARN
WARN是低級別異常日誌，反映系統在業務處理時觸發了異常流程，但系統可恢復到正常態，下一次業務可以正常執行。但WARN級別問題需要開發人員給予足夠關注，往往表示有引數校驗問題或者程式邏輯缺陷，當功能邏輯走入異常邏輯時，應該考慮記錄WARN日誌。
INFO
INFO日誌主要記錄系統關鍵資訊，旨在保留系統正常工作期間關鍵執行指標，開發人員可以將初始化系統配置、業務狀態變化資訊，或者使用者業務流程中的核心處理記錄到INFO日誌中，方便日常運維工作以及錯誤回溯時上下文場景復現。
DEBUG
DEBUG日誌是INFO日誌的好幫手，開發人員可以將各類詳細資訊記錄到DEBUG裡，起到除錯的作用，包括引數資訊、除錯細節資訊、返回值資訊等。其它等級不方便顯示的資訊都可以透過DEBUG日誌來記錄。
2、記錄日誌的時機，一定要仔細考量
在排除故障的時候，該要出現的日誌沒有，無用的日誌一大堆，或者需要的資訊分散在各個角落，特別是遇到緊急的線上bug時，有效的日誌被大量無意義的日誌資訊淹沒，焦急且無奈地浪費大量精力查詢日誌。那什麼是記錄日誌的合適時機呢？
當方法或者功能處理過程中產生不符合預期結果或者有框架報錯時可以考慮使用，常見問題處理方法包括：
“增加判斷處理邏輯，嘗試本地解決 丟擲異常，交給上層邏輯解決 記錄日誌，報警提醒 使用返回碼包裝錯誤做返回”
DEBUG級別。 系統初始化：系統或者服務的啟動引數。核心模組或者元件初始化過程中往往依賴一些關鍵配置，根據引數不同會提供不一樣的服務。務必在這裡記錄INFO日誌，打印出引數以及啟動完成態服務表述。
程式語言提示異常：如今各類主流的程式語言都包括異常機制，業務相關的流行框架有完整的異常模組。這類捕獲的異常是系統告知開發人員需要加以關注的，是質量非常高的報錯。應當適當記錄日誌，根據實際結合業務的情況使用WARN或者ERROR級別。
業務流程預期不符：除開平臺以及程式語言異常之外，專案程式碼中結果與期望不符時也是日誌場景之一，簡單來說所有流程分支都可以加入考慮。取決於開發人員判斷能否容忍情形發生。常見的合適場景包括外部引數不正確，資料處理問題導致返回碼不在合理範圍內等。
系統核心角色，元件關鍵動作：系統中核心角色觸發的業務動作是需要多加關注的，是衡量系統正常執行的重要指標。建議記錄INFO級別日誌，比如電商系統使用者從登入到下單的整個流程；微服務各服務節點互動；核心資料表增刪改；核心元件執行等，如果日誌頻度高或者列印量特別大，可以提煉關鍵點INFO記錄，其餘酌情考慮
3、日誌也會消耗效能，要牢記效能意識，不要隨意浪費資源
所有的日誌工具，在日誌輸出時總會對效能產生或多或少的影響，為了將影響降低到最低，有以下幾個準則需要遵守：
根本原則：有必要才記錄日誌，頻繁過量日誌對效能是有損耗的，並且這種風險不常在系統正常時出現，系統出現問題時大量ERROR、INFO等問題相關日誌有可能產生連鎖反應，造成嚴重的後果。將關鍵資訊儲存到日誌，同時考慮極端場景日誌爆發。
Logger獲取：根據系統使用的日誌框架組合，確定正確的例項獲取方式。在log4j的早期版本，一般要求使用static，而在高版本以及後來的slf4j等一些框架封裝中，該問題已經得到最佳化，獲取（建立）logger例項的成本已經很低。但對於多例，尤其是需要頻繁建立的class，推薦新增static字首。
輸出等級校驗：在log4j 1.x版本，對於可以預見的會頻繁產生的日誌輸出，先判斷一下(logger.isXXXEnabled()，對於效能有很大提升，在其它外觀框架或者log4j 2.x中已經自動實現。 輸出格式：禁止使用字串拼接，使用引數方式。 樣式配置：佈局配置輸出的資訊也會影響到效能，需要根據logger的具體使用場景來選擇輸出合適資訊。
核心都是減少日誌量 ，前兩點偏向設計，後四點偏向日誌框架及習慣，並且這四點目前一些框架組合已經能幫開發人員減少不少工作，比如log4j2.x在例項獲取，輸出等級判斷都有最佳化。
1、日誌的級別一定要搞清楚
ERROR
ERROR是最高級別錯誤，反映系統發生了非常嚴重的故障，無法自動恢復到正常態工作，需要人工介入處理。系統需要將錯誤相關痕跡以及錯誤細節記錄ERROR日誌中，方便後續人工回溯解決。
WARN
WARN是低級別異常日誌，反映系統在業務處理時觸發了異常流程，但系統可恢復到正常態，下一次業務可以正常執行。但WARN級別問題需要開發人員給予足夠關注，往往表示有引數校驗問題或者程式邏輯缺陷，當功能邏輯走入異常邏輯時，應該考慮記錄WARN日誌。
INFO
INFO日誌主要記錄系統關鍵資訊，旨在保留系統正常工作期間關鍵執行指標，開發人員可以將初始化系統配置、業務狀態變化資訊，或者使用者業務流程中的核心處理記錄到INFO日誌中，方便日常運維工作以及錯誤回溯時上下文場景復現。
DEBUG
DEBUG日誌是INFO日誌的好幫手，開發人員可以將各類詳細資訊記錄到DEBUG裡，起到除錯的作用，包括引數資訊、除錯細節資訊、返回值資訊等。其它等級不方便顯示的資訊都可以透過DEBUG日誌來記錄。
2、記錄日誌的時機，一定要仔細考量
在排除故障的時候，該要出現的日誌沒有，無用的日誌一大堆，或者需要的資訊分散在各個角落，特別是遇到緊急的線上bug時，有效的日誌被大量無意義的日誌資訊淹沒，焦急且無奈地浪費大量精力查詢日誌。那什麼是記錄日誌的合適時機呢？
當方法或者功能處理過程中產生不符合預期結果或者有框架報錯時可以考慮使用，常見問題處理方法包括：
“增加判斷處理邏輯，嘗試本地解決 丟擲異常，交給上層邏輯解決 記錄日誌，報警提醒 使用返回碼包裝錯誤做返回”
DEBUG級別。 系統初始化：系統或者服務的啟動引數。核心模組或者元件初始化過程中往往依賴一些關鍵配置，根據引數不同會提供不一樣的服務。務必在這裡記錄INFO日誌，打印出引數以及啟動完成態服務表述。
程式語言提示異常：如今各類主流的程式語言都包括異常機制，業務相關的流行框架有完整的異常模組。這類捕獲的異常是系統告知開發人員需要加以關注的，是質量非常高的報錯。應當適當記錄日誌，根據實際結合業務的情況使用WARN或者ERROR級別。
業務流程預期不符：除開平臺以及程式語言異常之外，專案程式碼中結果與期望不符時也是日誌場景之一，簡單來說所有流程分支都可以加入考慮。取決於開發人員判斷能否容忍情形發生。常見的合適場景包括外部引數不正確，資料處理問題導致返回碼不在合理範圍內等。
系統核心角色，元件關鍵動作：系統中核心角色觸發的業務動作是需要多加關注的，是衡量系統正常執行的重要指標。建議記錄INFO級別日誌，比如電商系統使用者從登入到下單的整個流程；微服務各服務節點互動；核心資料表增刪改；核心元件執行等，如果日誌頻度高或者列印量特別大，可以提煉關鍵點INFO記錄，其餘酌情考慮
3、日誌也會消耗效能，要牢記效能意識，不要隨意浪費資源
所有的日誌工具，在日誌輸出時總會對效能產生或多或少的影響，為了將影響降低到最低，有以下幾個準則需要遵守：
根本原則：有必要才記錄日誌，頻繁過量日誌對效能是有損耗的，並且這種風險不常在系統正常時出現，系統出現問題時大量ERROR、INFO等問題相關日誌有可能產生連鎖反應，造成嚴重的後果。將關鍵資訊儲存到日誌，同時考慮極端場景日誌爆發。
Logger獲取：根據系統使用的日誌框架組合，確定正確的例項獲取方式。在log4j的早期版本，一般要求使用static，而在高版本以及後來的slf4j等一些框架封裝中，該問題已經得到最佳化，獲取（建立）logger例項的成本已經很低。但對於多例，尤其是需要頻繁建立的class，推薦新增static字首。
輸出等級校驗：在log4j 1.x版本，對於可以預見的會頻繁產生的日誌輸出，先判斷一下(logger.isXXXEnabled()，對於效能有很大提升，在其它外觀框架或者log4j 2.x中已經自動實現。 輸出格式：禁止使用字串拼接，使用引數方式。 樣式配置：佈局配置輸出的資訊也會影響到效能，需要根據logger的具體使用場景來選擇輸出合適資訊。
核心都是減少日誌量 ，前兩點偏向設計，後四點偏向日誌框架及習慣，並且這四點目前一些框架組合已經能幫開發人員減少不少工作，比如log4j2.x在例項獲取，輸出等級判斷都有最佳化。