業務系統日志記錄規范

注意

應用中應該充滿了日志記錄信息，日志甚至比邏輯代碼還要多；

集成 seluth ，開啟消息鏈路；不開啟日志上傳,不集成 zipkin;

應該避免日志記錄過程中出現異常，比如 log.debug(requst.getid) ,這條日志記錄之前一定要判斷 request 是否為空；日志記錄中使用的信息一定時穩定的，提前準備好的，最好不是專門為此次日志記錄專門準備的；

日志應只記錄標識性信息，具體信息從具體存儲里取；

日志應該同時支持人和計算機都可以讀；人可讀的意思的，要成句子；計算機可讀的意思是要有明確的分割符，可以支持正則等工具抽取其中有意義的信息；

service 或 manager 層內有 if…else 或者 switch 這樣的分支時，要在分支的首行打印日志，用來確定進入了哪個分支；

對于 trace / debug / info 級別的日志輸出,必須進行日志級別的開關判斷。warn 和 error 不用開關判斷；

日志級別 trace 和 debug

測試環境要實現的目標是，不需要重新完整的調試程序，可以直接定位到出問題的 service 內的邏輯分支，最多在進行一次小范圍的測試；
要實現這個目標，需要記錄 service 入參出參，debug級別的日志，只在非生產環境中使用；

日志級別 info

info級別的日志只在 service 層和 manager 層存在，體現業務邏輯運行的路徑，工具類等的不要記錄；

Service 方法中對于系統/業務狀態的變更處記錄

主要邏輯中的分步驟記錄

日志級別 warn

有容錯機制的時候出現的錯誤情況，有異常，但是你有 Plan B;

業務異常的記錄,比如:當接口拋出業務異常時，應該記錄此異常;

warn 日志級別來記錄用戶輸入參數錯誤的情況,避免用戶投訴時,可以追溯信息;

日志級別 error

error 級別只記錄系統邏輯出錯、異常或者重要的錯誤信息。
異常在程序中，一般會沿著調用鏈路，層層上拋，直到service層，在最終處理異常的地方記錄log.error(e)；log.error和往外拋異常，不應該同時出現；

錯誤異常

錯誤異常分為程序異常（系統異常）和業務異常；

程序異常會導致程序不能正常執行；業務異常不會，業務異常的處理屬于業務邏輯的一部分；
ERROR 級別的日志，一出，意味著開發運維人員要介入了，要操作確認一下東西，要維修一些東西了；

業務系統開發過程中，不需要 log.error 記錄異常，讓框架和容器（Tomcat等）來做；
業務異常的需要開發者開發對應的異常處理邏輯，業務異常不是程序異常；比如用戶登陸失敗；
業務異常的處理屬于正常的業務邏輯，不應該log.error，不重要的可以不log，重要的可以使用log.warn記錄，避免用戶投訴時,可以追溯信息;

數據庫或者kafka在應用啟動時連不上是如何處理的，在應用運行過程中是如何處理的？啟動時，依賴的插件有問題，應用直接啟動不起來；如果應用已經啟動起來了，觸發到跟其交互時，拋出異常，程序還是正常執行；

ExceptionHandler的默認的處理邏輯

ExceptionHandler的默認的處理邏輯不要吃掉所有的異常，log.error打印出來，這個邏輯主要用來處理程序異常，業務異常都應有對應的處理邏輯；

@ExceptionHandler(Throwable.class) @ResponseBody public String handle(Throwable e) {log.error(e.getMessage(),e);//構造返回信息return e.getMessage(); }

程序異常

各個組件的異常信息可以各自處理；比如SQLExcption，需要如果SQL 出異常，異常的信息中會有SQL相關的信息，如果直接返回給前端，會造成安全問題，前端對此異常也不關心，而后端開發者關心的信息應該都記錄在日志中，以方便分析問題；

@ExceptionHandler(SQLException.class) @ResponseBody public String handle(SQLException e) {log.error(e.getMessage(),e);//構造返回信息，記得脫敏return e.getMessage(); }

各個組件的SDK一般都會有自己的異常體系；可以根據情況直接對頂級異常類，或者典型的異常子類進行處理；
接入外部組件時，首先分析其SDK的異常體系，編寫對應的ExceptionHandler

org.apache.kafka.common.KafkaException
org.springframework.kafka.KafkaException
java.sql.SQLException

鏈路追蹤

多個進程間的日志聯動
集中式日志存儲系統的存在，讓在一個入口處理業務系統的日志成為了可能，產生了高級的用法，鏈路追蹤；
用戶的一個動作觸發的在各個系統的所有的執行邏輯，使用一個標識將其聯系起來，開發人員分析的時候，可以根據此標識查詢所有相關的日志，哪里出問題，一目了然；

遠程調用

遠程調用的plan b，就是熔斷降級里面的Plan B；
外部接口部分,客戶端請求參數(REST/WS),調用第三方時的調用參數和調用結果使用info

如果出異常，調用過程異常或者返回錯誤碼，根據情況選擇拋出異常或者啟用Plan B；
拋出異常意味著程序正常流程執行結束，需要處理這個異常，warn記錄此異常，然后返回用戶結果；
Plan B意味著程序還可以正常執行下去，warn記錄發生了此事件，出現異常轉入Plan B；

遠程調用過程中出異常，意味著需要開發人員介入，應該記錄 error 級別的異常；
如果是返回的錯誤碼是非成功執行的錯誤碼，這時候應該根據錯誤碼的級別拋出不同的異常，處理異常的地方根據遠程調用的接口的重要程度評估使用不同的日志級別。

驗證日志

提交代碼前，確定通過日志可以看到一個功能的整個執行流程，可以通過日志進行問題定位程序執行的路徑；

參考

用JAVA日志來寫詩
JAVA - 優雅的記錄日志(log4j實戰篇)
Alibaba Java Coding Guidelines
小白學習如何打日志
正確的打日志姿勢
Java常用日志框架介紹

總結

以上是生活随笔為你收集整理的业务系统日志记录规范总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。