為什麼日誌只應該有三個層級

日誌只需要三種層級：normal、error、debug。

其中normal用來記錄一般性的程式運行資訊，error用來記錄必須處理的錯誤資訊，debug用來記錄詳細的調試資訊。程式普通啟動並執行時候只開normal和error日誌；當需要追蹤問題的時候再開debug日誌。

這分別代表了我們能夠做出的三種反應：日常查看狀態（normal）、發現需要關註解決的問題（error）、調試分析問題（debug）。

因為我們只能對日誌做出這三種反應，因此日誌只應該被分成這三個層級。

java裡面的日誌是被分成九個層級的，那基本上只造成了混亂。比如warning層級，這純粹是扯淡，沒人知道該怎麼處理warning，是必須處理掉，還是不用處理？在現實世界裡，所有warning實際上都會被無視，變得無意義。

作為佐證，我曾經見過某大公司的一些java項目，那些項目的日誌都亂七八糟，因此日常維護的時候也基本上都忽略了所有日誌。之所以大多數程式員都不知道該怎麼寫日誌，是因為他們缺乏一個可執行檔指引：什麼資訊該寫哪個類型的日誌。經常有程式員會把必須處理的錯誤寫在warning裡面，導致error日誌不能覆蓋所有必須處理的錯誤，從而使得監控error日誌變得無意義。

之所以日誌必須只分為三個層級，是為了能給程式員提供一份清晰的指引：凡是需要處理的錯誤，都必須寫error日誌；其他資訊都寫normal，而normal資訊都是不用處理的，不影響系統啟動並執行；調試資訊寫debug。

Q：當收到一個異常的request的時候，是否需要寫error日誌？

A：如果這個異常request是預期之內的，則寫normal日誌；如果這個request是需要程式員或者營運人員進行處理的，則寫error日誌。

Q：當系統啟動失敗的時候，應該寫什麼日誌？

A：啟動失敗是不應該的，需要營運人員至少看看為什麼。因此需要寫error日誌。

Q：當系統內部buffer隊列滿了的時候，應該寫什麼日誌？

A：在設計正確的系統裡面，正常情況下不應該出現buffer滿了的情況。這種情況需要程式員改代碼或者營運改配置。因此需要寫error日誌。