前言
雖然 logging level 各司其職，但目前就 Zam 看到的，看到台灣滿多都是 DEBUG level 從頭用到尾，變成只有 ERROR、DEBUG 這兩種存放多數的 LOG，有些看到 DEBUG level 就會以為開發 debug 用，所以開發中一律都用 DEBUG level 進行記錄，最後 log 就這樣上 production environment，因此會導致偵錯上會有多餘的 log 影響 debug。多瞭解一點 logging level 可以讓別人 debug 或開發上輕鬆許多。
Logging Level 的優先順序
ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF
當你設定越高的層級，你的 log 量也會飛快的飆升，所以一般而言在正式的 production environment，只會預設為 WARN or ERROR。
例如你設定為 ERROR，那就只會顯示 loggging level 為 ERROR and FATAL
常用 Logging Level 使用時機介紹
ALL
全部的 logging level，包含自定義、與其他為在此介紹的 logging level 都會顯示。
TRACE
通常會放些讓 Developer 在追 bug 時，可以補足 ERROR 或 WARN 的 context 資訊。
1. 使用者目前是進行什麼功能的操作
2. 使用者目前操作的步驟流程
DEBUG
通常會放些對於 Developer、IT、System Admin 等可以釐清問題的 log
1. 分析效能相關，例如執行時間
2. 分析錯誤相關
INFO
通常會放些重要的成功訊息並讓 QA 可以進行確認
主要提供關鍵的狀態供快速判斷系統狀態
1. service 啟動成功與否
2. 關鍵的 transactions 被執行完成與否
3. configuration
WARN
可以用來警示的錯誤，出現時可以提供分析的資訊
1. 網路暫時中斷
2. 轉換的型態可能造成資料遺失
3. 定時執行的任務失敗
ERROR
一般的錯誤，出現了就需要思考並排時間解決
1. 網路連線無預期中斷且無法連回
2. 傳輸資料失敗
3. CRUD database 失敗
4. 諸如此類會影響功能的錯誤
FATAL
最緊急的錯誤，只要一出現此類的錯誤，半夜看到也要從床上跳起來立刻給 hotfix 那種。
1. 會嚴重影響財損的錯誤
2. 通常此錯誤發生就會讓服務暫時停止運作
OFF
這個相當於關掉 logging 功能，不會有 log 產出。
結論
希望當你要進行 log 卻不知道該用哪個，看完這篇可以不要一昧的使用 DEBUG ，開始多用其他的 logging level 來分類資訊。有些人會認為 INFO 比 WARN 重要，所以有時候 default level 是 WARN 時，INFO 也會跟著印出，但這只是算是例外，他們會自己 wrapping logging library 達到需求。
除此之外，也可以進行檔案上的分流，將 log 檔分為 service.log 跟 service-critical.log，當你開啟 INFO level 或者 DEBUG level，可以特別將 WARN 跟 ERROR 放在 critical，才不會被大量的 DEBUG log 洗掉 WARN 跟 ERROR。
