這篇文章的草稿，在 2023 年寫了一半，一放又是兩年過去了。趁著前幾天寫了 系統開發實務對談記錄：Log 與 Error Handling 後，打鐵趁熱，一口氣把這一篇也補完。
🔖 長話短說 🔖
- 回歸初心：釐清 Log 的核心目的，是為了解決問題，而不只是記錄。
- 適量即可：Log 不是越多越好，應專注在關鍵部分，避免過度記錄造成效能負擔。
- 結構化日誌：採用標準化的格式 (如 JSON)，包含時間戳、事件類型、堆疊追蹤等資訊，方便後續的分析與查詢。
- Log 分級：透過
Info、Warning、Error等級別，快速過濾與定位問題。- 非同步處理：將 Log 寫入的動作與主要業務邏輯解耦，降低對系統效能的影響。
在軟體開發中，有個每位開發人員都會遇到的議題，那就是 Log 要寫多少？要寫什麼內容？
常有人說 Log 太多會影響系統效能，也有人說 Log 記的太少，無法排除問題，只能通靈。
所以我們來聊聊 Logs 的目標，要寫多少? 要看什麼資訊? 還有可以有那些應用？
為何而記？
在深入探討 Log 的設計之前，我們必須先回歸初心：「我們到底想用 Log 來解決什麼問題？」
一個適量的 Log，不僅能幫助開發人員更容易地進行 Debug，更能提供系統運行時的重要資訊。然而，過多的 Log 卻可能讓程式變得複雜，甚至成為系統的效能瓶頸。
因此，「適量」是關鍵。我們應該選擇性地在程式的關鍵部分，或是在問題發生時，才加入足夠的 Log 來追蹤問題，而不是無差別地記錄所有事情。
一個好的 Log 策略，可以幫助我們：
- 快速定位問題：在錯誤發生時，提供精確的線索。
- 了解程式運行情況：掌握系統的健康狀況與執行流程。
- 檢查系統效能：找出效能瓶頸與不穩定的地方。
- 提供維運資訊：協助維運人員監控與管理系統。
雖然在 系統開發實務對談記錄：Log 與 Error Handling 這一篇中，我們有提到了 Log 的分級，以及應該要記錄那些資訊。(有興趣的可以回頭看一下。)
若我們把 Log 依嚴重度由低到高進行排序，越嚴重的，所包含的資訊就越加豐富。
舉例來說，系統內有這些有這些資訊可以取用。
- 時間戳 (Timestamp)：事件發生的精確時間。
- 日誌級別 (Log Level)：例如
Error、Warning、Info等。 - 事件類型 (Event Type)：對事件的分類，例如
Authentication、Database。 - 訊息 (Message)：簡潔明瞭的事件描述。
- 堆疊追蹤 (Stack Trace)：當錯誤或例外發生時的程式碼呼叫路徑。
- 使用者資訊 (User Identity)：是哪個使用者觸發了這個事件。
- 請求資訊 (Request Information)：例如
URL、Parameters、Headers等。 - 系統資訊 (System Information)：例如伺服器名稱、IP 位址、資源使用狀況。
在 Information 層級的 Log，可能只需要記錄 時間戳、日誌級別、事件類型、訊息 這些資訊就足夠了。
當上升到 Error 層級時，因為需要更多資訊來鎖定問題點，除了 時間戳、日誌級別、事件類型、訊息 這些資訊外，還需要有 堆疊追蹤、請求資訊之類，更加詳細的資訊。
除了使用 Log 來定位問題，了解系統運行情況的應用，我們也來聊聊其它的部分。
資訊安全
避免記錄機敏資料
在記錄 Log 時，務必注意不要將使用者的個人隱私、密碼、金鑰等機敏性資料寫入 Log，以免造成資安風險。
與系統資源的平衡點
Log 對效能的影響
許多人擔心記錄 Log 會影響系統效能。確實，如果 Log 的寫入是同步執行的，那麼在大量的 Log 請求下，勢必會對系統造成影響。
為了解決這個問題，我們可以採用非同步 (Asynchronous) 的方式來處理 Log。將 Log 的寫入動作，放到一個獨立的背景執行緒或佇列中，讓它與主要的業務邏輯脫鉤，如此一來，就能大幅降低對系統效能的衝擊。
關於
該包含哪些資訊？
一個有效的 Log，應該像一份詳盡的「案發現場報告」。根據需求的不同，Log 中可以包含以下資訊：
log 可以幫助開發人員：
快速定位問題 了解程式的運行情況 檢查系統的性能和穩定性 提供運維人員所需的資訊 支援監控和問題追蹤 除此之外，log 也可以被統計分析，以了解系統的使用情況，以改善服務品質。
Logs 破碎的問題
Logging、Tracking、metric
log metric 是指從 log 中提取的數據，用於監控和分析系統運行狀態。常見的 log metric 包括:
- 錯誤率：錯誤 log 數量除以總 log 數量的比率。
- 記憶體使用率：記憶體使用量除以總記憶體量的比率。
- CPU 使用率: CPU 使用時間除以總 CPU 時間的比率。
- 網路流量：網路流量的總量。
- 時間戳記：時間戳記的總量。
- 請求數量：網路請求數量的總量。
- 回應時間：請求回應時間的平均值或總和。
- 用戶在線時間：用戶在線時間的平均值或總和。
- 用戶行為：用戶行為的總量，例如點擊次數、停留時間等。
- 效能指標：效能指標的總量，例如 QPS、并發數量等。
這些 metric 可以幫助開發人員了解系統運行狀態，並支援監控和優化系統性能。此外，也可以根據組織需求對 log 數據進行自定義的計算。
logging, tracking, and metric 是三個有關於系統運行狀態的概念。
logging 是將系統運行狀態的訊息記錄下來的過程。通常，log 包含了系統運行狀態的詳細資訊，例如錯誤訊息、警告、跟蹤等。 tracking 是追蹤系統運行狀態的過程。通常，tracking 涉及到記錄系統運行狀態的資訊，例如使用者行為、網路請求、錯誤等。 metric 是從 log 和 tracking 中提取的數據，用於監控和分析系統運行狀態。通常，metric 涉及到指標，例如錯誤率、記憶體使用率、CPU 使用率、網路流量等。 總結來說，logging 是記錄系統運行狀態的過程，tracking 是追蹤系統運行狀態的過程，而 metric 是從 log 和 tracking 中提取的數據，用於監控和分析系統運行狀態。
小結
Log 的設計是一門權衡的藝術。我們需要在「資訊完整度」與「系統效能」之間找到一個平衡點。透過釐清 Log 的目的、採用結構化日誌、做好 Log 分級，並以非同步的方式處理，我們就能打造出一個既能快速排查問題，又不會對系統造成過大負擔的日誌系統。
補充資料
▶ 站內文章
▶ 外部文章