日誌說明以及格式統一規範

fatal、error、warn、info、debug、trace，級別越高儲存優先順序越高，原則上對於error及以上級別的日誌永久保留，對於此級別以下的，級別越高保留時間越長。

• request && response

• 系統操作行為：讀寫檔案、定時任務等

• 不符合業務邏輯預期：列印關鍵的引數，要能從這些引數中清楚地看出，誰的操作與預期不符，為什麼與預期不符。並且唯一定位到這條日誌，要包含使用者id或者流水號

• 對外提供的介面入口處：列印介面的唯一標識和簡短描述，並且要將呼叫方傳入的引數原樣列印出來，這樣當系統出現問題時，就能很容易的判斷出是否是呼叫方出現了問題

• 呼叫其它系統介面的前後：列印所呼叫介面的系統名稱/介面名稱和傳入引數/響應引數，這樣能方便做問題定界，通過這兩條日誌可以清楚地看出是否是所呼叫的系統出現了問題

• 系統模組的入口與出口處：可以是重要方法級或模組級，記錄它的輸入與輸出，方便定位

• 非預期執行：為程式在「有可能」執行到的地方列印日誌

• switch case語句塊中的default

• if…else if…else中很少出現的else情況

• try catch語句塊中catch分支。

• 服務狀態變化(盡可能記錄線索)：程式中重要的狀態資訊的變化應該記錄下來，方便查問題時還原現場，推斷程式執行過程

• 一些可能很耗時的業務處理：批處理，io操作

• 程式執行耗時：通過它可以跟蹤為什麼系統響應變慢或者太快

• 大批量資料的執行進度

• 程式入口：在入口列印日誌是因為這個時候傳遞進來的引數沒有經過任何處理，將它列印在日誌檔案中能一眼就知道程式的原始資料是否符合我們的預期，是不是傳遞進來的原始資料就出現的問題。

• 計算結果，測試關心的程式的輸出結果是否符合預期，那麼對於計算過程不應該關心，僅給出計算結果就能判斷是否符合預期。

• 重要資訊：這一點可能很寬泛，因為不同的業務邏輯重點可能並不一樣，例如在有的重要引數不能為空，此時就需要判斷是否為空，如果為空則記錄到日誌中；還有的例如傳遞進來的引數經過一系列的演算法處理過後，此時也需要列印日誌來檢視是否計算正確。但切記，盡量不要直接在for迴圈中列印日誌，特別是for迴圈特別大時，這樣你的日誌可能分分鐘被衝得不見蹤跡，甚至帶來效能上的影響。

• 異常捕獲：在異常列印出詳細的日誌能讓你快速定位錯誤在**，例如在程式丟擲異常捕獲時，在平時我們經常就是直接在控制台列印出堆疊資訊e.printstacktrace()，但在實際的生產環境更加艱苦，更別說有ide來讓你檢視控制台資訊，此時就需要我們將堆疊資訊記錄在日誌中，以便發生異常時我們能準確定位程式在**出錯。

• 讀寫配置檔案失敗

• 網路斷線

• 所有第三方對接的異常(包括第三方返回錯誤碼)

• 所有影響功能使用的異常

日誌格式可以參考，我制定的格式如下，如果業務不一樣也可以修改

低級別日誌，一般不使用，如有特殊情況則使用預設格式。

開發環境日誌，生產環境不使用，測試環境可使用，格式使用預設格式

記錄型日誌，在預設格式的基礎上增加記錄內容說明，格式如下：

日期、時間、所屬業務、日誌級別、**位置、記錄內容說明、日誌內容

記錄型日誌，格式和info格式一致，但是比info級別日誌更加重要，格式如下：

日期、時間、所屬業務、日誌級別、**位置、記錄內容說明、日誌內容

錯誤型日誌，記錄系統使用中發現的錯誤，格式為預設格式+錯誤碼，如下：

日期、時間、所屬業務、日誌級別、**位置、錯誤碼、日誌內容

最高端別錯誤型日誌，如果出現此錯誤，應該立即儲存資料停止整個系統執行，一般不使用此基本日誌，除非特殊情況。格式如下：

日期、時間、所屬業務、日誌級別、**位置、錯誤概要、錯誤詳情

說明：如果出現error以上級別日誌應該立即聯絡有關開發人員，如果出現fatal級別日誌應該立即儲存重要資料並通知整個有關部門，商量解決方案

我們在寫日誌的時候，需要注意輸出適當的內容。首先，盡量使用業務相關的描述。我們的程式是實現某種業務的，那麼就最好能描述清楚這個時候走到了業務過程的哪一步。其次，避免在日誌中輸出一些敏感資訊，例如使用者名稱和密碼。以及，要保持編碼的一致。如果不能保證就盡量使用英文而不是中文。這樣當我們拿到日誌之後就不會因為看到一堆亂碼而不知所云了。

日誌說明以及格式統一規範

BGP的訊息型別以及格式

nginx日誌格式說明

tomcat，httpd 日誌格式說明

日誌說明以及格式統一規範

BGP的訊息型別以及格式

nginx日誌格式說明

tomcat，httpd 日誌格式說明

相關推薦