頭兩天領導分配個任務是要把項目中所有try catch里的異常處理收集到elk中，由於之前的處理方式五花八門，就集中處理了下， 事后還被批評了。
不是所有的異常信息都需要被記錄到log中
使用SLF4J
- 使用門面模式的日志框架，有利於維護各個類的日志處理方式的統一。
- 實現方式的統一使用，使用logback框架。
什么時候應該打日志？
- 當你遇到問題的時候，只能通過debug功能來確定問題，你應該考慮打日志，良好的系統，是可以通過日志來定位問題所在的。
- 當你碰到if..else或者switch這樣的分支的時候，可以在首行打印日志，用來確定進入了那個分支。
- 經常以功能為核心進行開發的時候，可以在提交代碼前，通過日志看到整個流程。
基本格式
必須使用參數化信息的方式：
“ logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol); ”
對於debug日志，必須判斷是否為debug級別后，才進行使用。
不過不建議這樣做。因為上面的代碼涉及到了字符串的拼接， 會產生很多String對象，占用空間，影響程序性能。
可以使用 [{}] 進行參數的隔離
如果有參數變量，可以寫成下面這樣：
這樣的格式寫法，對於排查問題更有幫助。
不同級別的使用
ERROR
定義：影響到程序正常運行，當前請求正常運行的異常情況：
- 打開配置文件失敗
- 對接第三方的異常（包括第三方返回錯誤碼）
- 所有影響功能使用的異常。包括sqlException和除了業務異常之外的所有異常（runtimeException，Ecxception）
如果拋出了異常，就不要記錄error日志，有最終處理方式進行處理。
如下圖：
WARN
定義：不應該出現但是不影響程序，當前請求正常運行的異常情況：
- 有容錯機制的時候出現的錯誤情況
- 找不到配置文件，但是程序可以自動創建或者能夠繼續向下執行
- 緩存池占用接近臨界值的時候
- 接口拋出業務異常的時候
INFO
定義:系統運行信息，外部接口
- service中對於系統/業務狀態的變更
- 主要邏輯分步驟
- 客戶端請求參數
- 調用第三方的調用參數和調用結果
這里同樣也是要有所抉擇的，普通簡單service是沒有意義的。不是針對每個業務都這樣做，
這里對於復雜的業務邏輯，例如電商系統中的下訂單邏輯，工業系統的停送電邏輯等等
DEBUG
定義：可以填寫想知道的相關信息，最好有相關參數，生產環境需要關閉debug，如果需要開啟的話，需要使用開關進行管理，不能一直開啟
TRACE
定義：特別詳細的系統運行信息。業務代碼中，不要使用（除非有特殊用意，否則用debug代替）
trace的級別比debug還要低一些，並且會自動檢查級別，如果高於trace就跳過。
而debug是先生產要打印的語句，然后再檢查級別。如果高於debug就不輸出
所以要debug進行判斷，否則會生成多余的對象。