本文件旨在協助您為記錄記錄選擇正確的嚴重性。
Fuchsia 支援嚴重性為 FATAL
、ERROR
、WARNING
、INFO
、DEBUG
或 TRACE
之一的記錄記錄。本文概述 RFC-0003: Logging 中的規範準則。
嚴重程度 | 摘要 |
FATAL |
無法復原的錯誤事件。會造成終止。 |
ERROR |
程式可復原的意外事件,表示發生錯誤或不想要的程式行為。 |
WARNING |
在系統正常操作的情況下發生非預期的事件。 |
INFO |
通常為提供資訊的事件,通常為錯誤報告中的最低層級。 |
DEBUG |
開發用的實用資訊事件。 |
TRACE |
用於開發的實用資訊,可透過精細程度或高頻率發出。 |
不確定要選哪一種嗎?
記錄會描述系統中的事件。選擇記錄檔記錄的嚴重性是說明事件本身的方式之一。
意外事件通常應該記錄在 FATAL
中,如果是無法復原的事件,ERROR
表示可復原的事件,該事件代表不正確的程式行為 (即「bugs」),而 WARNING
則表示可復原事件本身,但這些事件本身並非其他錯誤,但這些事件可能有其他失敗情況的重要背景資訊。
您應該將僅與在本機使用專案本機的貢獻者相關的事件記錄為 DEBUG
或 TRACE
。如果事件會預期發生,通常應將其記錄為 INFO
。
如果您還是不確定如何標示活動嚴重性,請考量下列問題:
活動發生了什麼變化?活動前後有何差異?
這通常是在撰寫或閱讀相關活動郵件時發送的郵件。如果系統中沒有發生變更,最好略過事件。對於重要的活動訊號事件,請考慮
TRACE
嚴重性。誰想瞭解這個活動?
根據預設,不同嚴重性的事件會在不同的情境下提供,而這些事件會定義目標對象。許多事件都與處理專案的工程師相關,但可能會為其他團隊產生過多雜訊。一般而言,建議以
DEBUG
或TRACE
嚴重性來發出這類事件,因為在預設情況下,這類事件不會納入錯誤報告中。由於
INFO
以上版本比較顯眼,因此在偵錯時並未為實作項目提供重要內容的事件應只提供對用戶端或實作團隊外部人員有幫助的資訊。這是週期性或持續進行的活動嗎?
說明頻繁背景活動或持續失敗狀態的記錄事件應限制為
DEBUG
或TRACE
,同時也會由檢查和 Cobalt 回報,避免實際工作環境中出現垃圾記錄檔。雖然輸入失敗狀態有助於記錄,但記錄「仍在故障狀態」這類的事件通常並不實用。失敗狀態是「波動」或定期自行解決問題並自行解法時,很難避免以這種方式重複記錄陳述式。依重複次數或時間間隔限制頻率限制是適當的回應方式,但 Fuchsia 的記錄程式庫目前不提供現成的工具。日後如果出現更明確的模式和最佳做法,就可能會繼續探索。