审计日志第 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项目设置"可以在服务端记录，但"谁在自己的管理后台修改了客户信息"则需要在应用程序端进行记录。

还可以查看无头CMS的操作历史

在 microCMS、Kuroco、NILTO 等无头 CMS 中，都提供了内容更新历史记录和管理面板操作日志功能。

谁更新了文章、何时发布、更改了设置或权限等记录，是网站运营中重要的审计日志。

但是，所记录的操作、可查看的时间段和可用的计划因服务而异。

即使能够查看内容更新历史，也不是所有管理操作都会作为审计日志保留。

此外，CMS 基本上只记录 CMS 内部的操作。已发布网站的访问情况和前端发生的错误需要在托管环境中查看。

在无头 CMS 项目中，不仅要看 CMS，还要把前端、托管、API 作为一个整体系统来理解会更清楚。

添加 Datadog 或 Sentry 时

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

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

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

两者都很便利，但部署它们并不能自动完成审计日志。

需要在应用程序端决定输出什么内容，而且如果长期保存所有日志，费用会随着数据量的增加而增加。

保存方式	适用场景	特点
管理后台·日志管理服务	日常故障排查	可快速搜索，但费用会随保存量增加而增加
R2、S3 等存储服务	审计、证迹的长期保管	可以低成本保存，但调查时需要进行提取操作

将日常搜索的日志与需要为应急情况保留的日志分开存储是现实的做法。