稽核日誌第3部：將Web服務的日誌設計落實到實務

應用程式端應該記錄什麼以及要記錄到什麼程度

大家好，我是在 Liberogic 擔任 CTO 的大塚。

上一次我們比較了AWS、Cloudflare、Vercel、Supabase、headless CMS等各種服務的日誌功能。

每個服務都提供了執行日誌、錯誤日誌、管理操作記錄等功能。

那麼，如果將這些功能結合起來，是否就能涵蓋Web服務所需的所有日誌呢？

遺憾的是，事情沒有那麼簡單。

這是因為雲端服務自動保留的日誌，與我們自己開發的應用程式側必須記錄的日誌是不同的。

這次我們將整理一下在實際Web服務中如何考量日誌設計，並貼近實務層面進行說明。

僅靠服務端日誌無法了解的事項

如果使用Cloudflare Workers或Vercel Functions，處理的執行結果和錯誤在某種程度上會被自動記錄。

使用 Supabase，您可以檢查資料庫、身份驗證、API 等的日誌。

不過，服務方面只能掌握該服務內部發生的事項。

例如，即使知道資料庫的寫入成功了，也無法判斷這是「接受了查詢」還是「變更了會員資訊」。

這類業務上的事件需要在應用程式端進行標註並記錄。

並非所有內容都應該輸出到日誌中

為了應對調查，有時會想盡可能地將更多資訊輸出到日誌中。

但是，日誌越多並不一定越好。

如果記錄所有処理細節，真正需要的資訊會被淹沒。隨著日誌量增加，儲存和搜尋的成本也會隨之上升。

因此，我們在設計日誌時會留意處理的「邊界」。

例如在聯絡表單的情況下，

• 成功受理
• 因輸入內容有問題而拒絕
• 因垃圾判定而拒絕
• 資料庫儲存失敗
• 通知電子郵件發送失敗

等處理結果會改變的重點。

概念上是保留所有中途的細微變數或處理，而是選擇之後追溯過程時所需的關鍵事件。

日誌應作為資料而非文章保留。

日誌中包含可供之後搜尋的資訊，會比單純寫著「發生錯誤」更方便。

以固定格式記錄這些項目的做法稱為結構化日誌。

如果以 JSON 等格式統一項目，就能輕鬆進行搜尋，例如「只查看特定申請 ID 的處理」或「只提取出現錯誤的電子郵件傳送」。

不要將個人資訊寫入日誌

記錄聯絡表單的日誌時，有時會連姓名、電子郵件地址和查詢內容一起記錄。

雖然看起來對調查很方便，但這是應該避免的設計方式。

日誌可能會被轉送到多個服務或長期保存。如果其中包含個人資訊或驗證資訊，日誌本身就可能成為新的資訊洩露原因。

將詢問內容等業務資料保存在資料庫中，日誌中僅記錄用於識別詢問的 ID 和受理成功的事實。

需要時，會使用該 ID 與資料庫端的資訊進行核對。

從聯絡表單的角度考量

聯絡表單通常採用只發送通知郵件的結構。

不過，即使郵件發送成功，也不一定能保證對方收到。

因此，更安全的做法是先將聯絡內容存入資料庫，而將郵件作為對負責人的通知來處理。

透過這種結構，可以區分「聯絡本身未被送達」與「聯絡已被保存但通知郵件發送失敗」。

這種細微的差異在實際的聯絡處理中是非常重要的。

短期搜尋與長期保存的區分

在日常的故障調查中，能夠快速搜尋最近的日誌是很重要的。

另一方面，用於審計或事件調查的日誌，即使平時很少查看，也必須能在數個月甚至數年後取出。

近期調查所需的項目放在易於搜尋的位置，長期的證跡則移至成本低廉的保存地點。

做法簡單，但在實務上這種分類方式的效果相當顯著。

日誌和儀表板是不同的東西

光是有日誌，似乎就能了解所有存取次數、錯誤率等資訊。

但是，日誌和儀表板顯示的數值其實扮演不同的角色。

• 日誌：詳細調查逐筆事件
• 指標：彙總件數、比例、處理時間等
• 儀表板：掌握系統整體趨勢

日常狀態確認透過儀表板進行，發現異常時再用日誌詳細調查。

結合這兩者，能達到容易運維的狀態。

最低限度需要決定的事項

最後，整理日誌設計中需要確認的項目。

• 要記錄的事件
• 要納入記錄的項目
• 排除個人資訊和認證資訊
• 可搜尋最近記錄的期間
• 長期保存的記錄範圍
• 長期記錄的儲存位置
• 可檢視記錄的負責人
• 保存期間過後的記錄刪除方法

聽到「稽核記錄」這個詞，可能會覺得需要記錄所有操作，並導入龐大的記錄管理基礎設施。

另一方面，對於一般的網站或媒體網站，可以先從決定重要操作和處理結果開始，然後區分短期搜尋和長期保存。

重點不在於並排列出所使用服務的記錄功能，而在於檢視整個系統是否保留了必要的記錄。

保留什麼。

為什麼保留。

需要保留多長的時間。

只要整理清楚這三點，就能避免構成過於龐大，更容易依據專案設計合適的記錄方案。

記錄通常不太顯眼。

但是，當發生問題時能否說明「發生了什麼」，這是由最初的設計決定的。

像這樣踏實的基礎工作，必須妥善建立才行。

好的，那就這樣吧。