日誌記錄最佳實踐

譯自Optimal Logging

by Anthony Vallone

Google Testing Blog

要找到一個系統問題的根本緣由，你須要多長時間？5分鐘？仍是5天？若是你的答案接近5分鐘，很大多是由於你的生產環境和測試環境使用了很是好的日誌記錄。更常見的狀況是，諸如日誌、異常處理、甚至測試這類非核心的工做，被看成一種出現問題後的補救方式。同異常處理和測試同樣，日誌記錄真的也須要策略，不管是生產環境仍是測試環境。永遠不要低估日誌的做用。有了使用得當的日誌，你甚至能夠說debug不是必需的。下面是多年來對我很是有用的日誌記錄指導原則。

保持適度

切勿記錄過多。大量的磁盤空間被日誌佔用說明你沒有想過應該記錄什麼。若是記錄了太多，你就還須要設計出複雜的方法來減小磁盤訪問、保留歷史記錄、歸檔大量數據、以及在這些數據中查詢。最關鍵的是，你將發如今這麼多垃圾中找到有用信息是多麼的困難。

惟一一個比記錄過多日誌還差的事是，記錄的過少。日誌一般有兩個主要目的：定位問題和事件確認。若是你的日誌不能明確一個bug的緣由，或者某個事務是否執行，你就記錄的過少了。

適合記錄的：

• 重要啓動配置
• 錯誤
• 警告
• 持久性數據的更改
• 主要系統組件間的請求和響應
• 重要的狀態變化
• 用戶交互
• 有已知失敗風險的調用
• 較長時間的等待
• 長期運行任務的週期性進度
• 重要的邏輯分支和導向分支的條件
• 從高層方法來彙總處理流程的步驟和事件——避免在底層方法中記錄複雜流程的每一步驟

不適合記錄的：

• 方法入口——不要記錄方法入口，除非它很是重要或者是日誌處於調試級別。
• 循環中的數據——避免在循環的屢次迭代中記錄日誌。若是是小循環，或者是間歇性的記錄，倒也無妨。
• 大消息或者文件的內容——截斷或者使用一些有利於調試的方式進行彙總。
• 良性錯誤——那些不是真正錯誤的錯誤會令日誌的讀者感到困惑。當異常處理是執行成功的一部分時，有時會遇到這種狀況。
• 重複的錯誤——不要重複的記錄相同或者類似的錯誤。這樣可能會快速的填滿日誌，而且隱藏掉真正的問題。各類類型錯誤發生的頻率最好有監視器（monitor）處理。日誌只需捕獲問題的詳細信息。

多個日誌級別

不要把全部信息都記錄在同一個日誌級別中。絕大多數的日誌庫都提供多個級別，系統啓動時能夠進行指定。這樣能夠很方便的控制日誌詳盡程度。

典型的級別有：

• 調試——最詳細，可是隻有在開發或者調試時適用。
• 信息——最經常使用的級別。
• 警告——奇怪的或者不在預期以內的一些狀態，可是可接受。
• 錯誤——有錯誤發生，可是流程不受影響。
• 嚴重——流程沒法繼續，系統將關閉或者重啓。

從實際使用來說，只須要兩種級別的日誌配置：

• 生產環境——除了調試級別，其餘全開。若是生產環境發生了問題，日誌應該可以指明緣由。
• 開發和調試——編寫新代碼或是嘗試復現問題時，打開所有級別。

測試日誌一樣重要

日誌的質量對於測試代碼和產品代碼一樣重要。當一次測試運行失敗時，日誌應當明確的指出這個錯誤是來自測試自己仍是生產系統。若是作不到這一點，那麼測試的日誌是有問題的。

測試日誌應該必需包括：

• 測試執行環境
• 初始狀態
• 準備步驟
• 用例步驟
• 與系統的交互
• 指望的結果
• 實際的結果
• 清理步驟

利用臨時日誌隊列實現條件性的詳細信息控制

發生錯誤時，日誌應當包含大量的詳細信息。但不幸的是，當遇到一個錯誤時，致使這個錯誤發生的詳細信息可能已經沒法得到了。若是你遵從了「不要記錄過多」的建議，在錯誤日誌以前的那些日誌可能沒法提供足夠的細節。解決這個問題的一個好的方式是，在內存中建立臨時的日誌隊列。在事務的處理過程當中，將每一步的詳盡信息追加到隊列中。若是事務成功完成，丟棄這個隊列，只記錄一個彙總。若是發生了錯誤，就把錯誤和隊列裏的所有內容記錄下來。這一方法對於系統交互的日誌尤爲有效。

問題是機遇

當生產環境出現問題時，你必將集中精力尋找而且修復問題，可是也不要忘記考慮一下日誌。若是你費了很大力氣才找到問題的緣由，這將是個很是好的機會來改善你的日誌。修復問題前，先修復你的日誌記錄，使其能夠清楚的指明問題緣由。若是這個問題又一次發生，將會很容易辨認。

若是沒法復現問題，或者測試結果不肯定，改進日誌以即可以在問題再次發生時將其記錄下來。

在整個開發的生命週期內，都應該持續的利用問題來改進日誌。寫新代碼時，試着少用debug，只使用日誌。這些日誌是否可以說明發生了什麼？若是不能，日誌就是不充分的。

最好也記錄性能數據

記錄時間數據能夠用來幫助定位性能問題。例如，要找到一個大型系統的超時緣由是很困難的，除非你可以追蹤每個重要處理步驟的耗時狀況。這是很容易作到的，只需記錄那些可能會比較耗時的調用的開始和結束時間便可：

• 重要的系統調用
• 網絡請求
• CPU密集運算
• 鏈接設備的交互
• 事務

在多線程和多進程中追蹤痕跡

在涉及到多線程或多進程的處理時，要爲事務建立獨一的標識。事務初始化時建立ID，將它傳入每個爲此事務工做的部分。當記錄關於此事務的日誌時，每個部分都應該記錄下這個ID。這樣，在多個事務並行執行時，追蹤一個特定的事務會容易不少。

監控和日誌相互完善

一個生產服務應該既有日誌也有監控。監控提供了一種實時的對於系統狀態的統計彙總。它能夠提醒你，是否必定比例的某個類型請求失敗了，是否系統正在經受不正常的流量訪問，性能是否在降低，或者其餘的一些異常。在某些狀況下，只是這些信息就能夠爲找到問題緣由提供線索。不過，大多數狀況下，監控警報只是爲了簡單的觸發你的調查。監控將問題的症狀展示給咱們。日誌則針對各個事務提供了詳細的信息和狀態，這樣你才能全面的理解問題的緣由。