稽核日誌其2：網頁服務的日誌功能橫向比較

AWS、Cloudflare、Vercel、Supabase、headless CMS 還能保留什麼？

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

上次我們整理了存取日誌、應用程式日誌和審計日誌的區別。

這次我們將更具體地深入探討，在我們經常使用的 AWS、Cloudflare、Vercel、Supabase 和 headless CMS 中，能夠取得什麼樣的日誌。

話說回來，這不是在詳細比較各項服務的費用和功能。

由於各服務在「標準情況下保留什麼」和「之後最多能確認什麼」方面的特點差異相當大，我們將在這方面進行粗略的整理。

即使是相同的「記錄功能」，目標操作和保存期間也會有所不同。

另外，在管理畫面上顯示和作為稽核用途長期保存，是兩回事。

AWS 雖然日誌相關服務應有盡有，但仍需進行設定

AWS 的日誌相關服務相當完善。

例如，Lambda 和 API Gateway 等的執行狀況會被蒐集到 CloudWatch Logs。在 AWS 管理畫面或 API 上進行的操作可以用 CloudTrail 記錄。

簡而言之，

• CloudWatch Logs：查看應用程式和 AWS 服務的動作
• CloudTrail：查看誰對 AWS 環境做了什麼
• S3：長期保存日誌

這樣的角色分工。

從搜尋、監視、通知到長期保存都可以在 AWS 內部組建，因此對審計要求嚴格的系統也容易對應。

不過，「因為使用 AWS 就會自動保存所有內容」並不是這樣。

需要根據使用的服務分別設定日誌輸出，並決定保存期間和保存位置。正因為自由度高，事前設計是前提條件。

Cloudflare 區分短期調查和外部保存

在 Cloudflare Workers 中，可以用 Workers Logs 確認 console.log() 輸出的內容和錯誤。

這對於開發中的驗證和近期的故障調查非常便利，但如果需要保留長期的審計跡證，最好不要僅依賴標準的日誌畫面。

需要長期保存的日誌應考慮使用 Logpush 等工具，將其發送到 R2 或外部日誌管理服務。

此外，當使用 Cloudflare Pages 或 Workers 配信靜態網站時，並非所有存取都會記錄在 Worker 的執行日誌中。

網站能正常顯示，容易讓人誤以為「當然也會有存取日誌」，但靜態檔案配信和 Worker 執行是兩回事。

Cloudflare 雖然相對容易建立精簡的架構，但需要理解各個處理流經何處，才能正確設計日誌。

Vercel 易於確認 Next.js 日誌

在 Vercel 中，可以從管理界面確認 Next.js Functions 和 Server Actions 等輸出的日誌。

因為部署和執行日誌相鄰，對開發者來說易於理解，日常的錯誤調查也更輕鬆。

另一方面，日誌可查看的期間和外部轉送的範圍因方案而異。

如果想要長期保留日誌，需要使用 Drains 等其他機制，將其發送到外部儲存位置。

不僅是 Vercel，管理介面中顯示的日誌與為審計用途而長期保留的日誌是兩個不同的問題。

需要將這兩者分開確認。

Supabase 的日誌不僅限於資料庫

Supabase 是以 PostgreSQL 為中心的服務，但實際上除了資料庫之外，還包含身份驗證、API、儲存、Edge Functions 等多個功能。

由於可以從管理介面確認各項日誌，因此能輕鬆追蹤整個應用程式的運作情況。

此外，還有與身份驗證相關的日誌，以及用於確認 Supabase 管理介面中所執行操作的審計日誌。

但同樣需要注意的是，Supabase 的管理操作與您自建應用程式內的操作是分開的。

例如，「誰變更了 Supabase 的專案設定」可以由服務端記錄，但「在貴公司的管理介面中誰變更了客戶資訊」則需要由應用程式端記錄。

確認 Headless CMS 的操作履歷

microCMS、Kuroco、NILTO 等 Headless CMS 都提供了內容更新履歷和管理介面的操作日誌。

誰が文章進行更新、何時發佈、設定或權限有何改變等記錄，在網站營運中是重要的稽核日誌。

不過，記錄的操作類型、可查詢的期間和可使用的方案會因服務而異。

即使可以確認內容的更新歷史，也不是所有管理操作都一定會保留在稽核日誌中。

此外，headless CMS 基本上只保留 CMS 內部的操作記錄。公開網站的存取情況和 frontend 端發生的錯誤，需要在 hosting 環境端確認。

在 headless CMS 專案中，不只看 CMS，而是把 CMS、frontend、hosting 和 API 視為一個整體系統會更清楚。

新增 Datadog 或 Sentry 時

日誌分散在多個服務時，每次發生故障都得逐一打開各管理介面進行調查。

匯總至 Datadog 等日誌管理服務後，就能統一搜尋多個環境的日誌，並偵測異常並發送通知。

Sentry 也常被使用，但它擅長調查錯誤的發生位置和影響範圍。

這兩種服務都很方便，但導入後不會自動完成稽核日誌。

需要由應用程式端決定輸出的內容，而且長期保存所有日誌會導致成本隨著資料量增加而上升。

在實際運作中，將日常搜尋的日誌和需要為應急情況而保存的日誌分開才是切實可行的方式。

無法單純根據哪項服務更優秀來判定

無法單純比較日誌，就決定 AWS 最好或 Cloudflare 最好。

重點是要理解該專案需要記錄什麼內容。

• 調查服務錯誤
• 保留管理員的操作記錄
• 確認 CMS 的更新歷史
• 追蹤身份驗證和權限變更
• 為了審計目的而長期保存

一旦確認了需求，就能看清各項服務的標準功能能涵蓋的部分，以及需要額外機制的部分。

我們不會從一開始就準備龐大的日誌基礎設施，而是根據專案的需求和預算來規劃架構。

下次，我們將介紹當結合這些服務時，應用程式端應該輸出什麼樣的日誌，以及應該保存在何處。我們會涵蓋更接近實務的內容。

好的，那就這樣吧。