审计日志第2部分：Web服务日志功能横向比较 | 话题

AWS、Cloudflare、Vercel、Supabase、headless CMS中保留了什么？

你好，我是大塚，在Liberogic担任CTO。

上次我们整理了访问日志、应用日志和审计日志的区别。

这次我们将更具体地看看在AWS、Cloudflare、Vercel、Supabase、headless CMS等我们日常使用的服务中，可以获取什么样的日志。

不过，这里讨论的不是各项服务的费用或功能的细致比较。

由于各服务在「标准保留了什么」「之后可以确认到什么程度」方面差异很大，我们将这些特点进行粗略整理。

服务	主要可以确认的日志	长期保存的考虑方式	注意事项
AWS	执行、访问、管理操作	组合使用 CloudWatch 和 S3	每个服务需要单独配置
Cloudflare	Workers 执行、异常等	转发到 R2 或外部服务	静态交付与执行日志分离
Vercel	Functions、部署、执行日志	通过 Log Drains 等转发到外部	保存范围取决于套餐
Supabase	数据库、API、身份验证、管理操作	通过 Log Drains 等转发到外部	应用特有的操作需另行实现
Headless CMS	内容更新、管理操作	使用服务的历史记录和审计功能	目标操作和计划不同
Datadog／Sentry	汇总的日志、错误信息	根据用途和存储量进行设计	仅实施不能成为审计日志

即使是相同的「日志功能」，目标操作和保存期间也会有所不同。

另外，在管理界面上显示的内容与长期保存以供审计之用是两回事。

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 提供了内容更新历史和管理面板操作日志。

谁更新了文章、何时发布、何时更改了设置或权限——这些记录在网站运维中作为审计日志至关重要。

不过，记录的操作类型、可查阅的时间范围和可用的套餐因服务而异。

即使可以确认内容的更新历史，也不是所有管理操作都一定会作为审计日志保留下来。

此外，CMS 拥有的基本上是 CMS 内部的操作记录。对公开网站的访问和前端发生的错误需要在托管环境端进行确认。

在 headless CMS 项目中，与其只看 CMS，不如把 CMS、前端、托管和 API 作为一个统一的系统来看待会更清楚。

当添加 Datadog 或 Sentry 时

如果日志分散在多个服务中，每当发生故障时，就需要打开各个管理界面进行调查。

汇聚到 Datadog 等日志管理服务后，可以统一搜索多个环境的日志，并能检测异常并发送通知。

Sentry 也常被使用，但它擅长调查错误发生的位置和影响范围。

两者都很便利，但部署它们并不意味着审计日志就会自动完成。

需要由应用程序端决定输出内容，而且长期保存所有日志会导致数据量增加，成本也会随之上升。

保存方式	适用场景	特点
管理面板・日志管理服务	日常故障调查	可即时搜索，但保存量越大费用越高
R2・S3 等存储服务	审计、长期保存证明文件	保存费用低廉，但调查时需要取出数据

将日常搜索的日志和需要保管以备不时之需的日志分开是更现实的做法。