日誌常被當作出問題後才看的檔案。實際上，日誌設計決定了團隊能否回答四類問題：誰訪問了什麼，哪裡報錯了，表單是否提交成功，最近誰改了配置。沒有結構的日誌既佔空間，也無法幫助判斷。
訪問日誌回答入口問題
訪問日誌應包含時間、路徑、狀態碼、來源 IP、使用者代理、響應時間和必要的來源資訊。它可以幫助判斷是否存在異常掃描、某地區訪問失敗、舊連結大量 404 或某資源流量突然增長。
錯誤日誌回答系統問題
錯誤日誌應儘量包含錯誤型別、關聯請求、服務名稱和發生時間，但不應洩露密碼、私鑰或完整個人資料。對於 Node 服務、反向代理、資料庫和第三方介面，日誌位置要寫在運維文件裡。
表單日誌回答業務問題
表單提交是否進入資料庫、驗證碼失敗是否異常、郵件通知是否傳送成功，這些都需要記錄。否則客戶說“我提交了但沒人回覆”時，團隊無法判斷是使用者未提交、驗證碼失敗、郵件丟失還是內部處理遺漏。
| 日誌型別 | 主要用途 | 保留建議 |
|---|---|---|
| 訪問日誌 | 流量、狀態碼、來源 | 按容量滾動保留 |
| 錯誤日誌 | 故障定位、依賴異常 | 結合釋出週期保留 |
| 表單日誌 | 線索確認、垃圾提交 | 按隱私政策保留 |
| 變更記錄 | 釋出、配置、許可權 | 長期保留摘要 |
日誌保留要考慮隱私和成本
日誌可能包含 IP、路徑、表單欄位和內部操作資訊，不應無限期儲存。合理做法是分級保留：短期保留詳細日誌，長期保留摘要和關鍵變更記錄。這樣既能排查問題，也能減少不必要的資料風險。