应用程序方面应该记录什么以及记录到什么程度
你好，我是大塚，在Liberogic担任CTO。
上一次我们比较了AWS、Cloudflare、Vercel、Supabase和headless CMS等各项服务的日志功能。
各项服务都配备了执行日志、错误日志和管理操作记录等功能。
那么，如果将这些结合起来，Web服务所需的日志是不是就全部齐全了呢？
遗憾的是，事情没有那么简单。
这是因为云服务自动保存的日志和我们开发的应用程序方面必须记录的日志是两回事。
这次我们将整理一下在实际Web服务中如何考虑日志设计，并从接近实际工作的角度来分析。
仅凭服务方日志无法了解的信息
如果使用Cloudflare Workers或Vercel Functions，处理的执行结果和错误在一定程度上会被自动记录。
使用 Supabase，您可以查看数据库、身份验证、API 等的日志。
不过，服务方能掌握的只是该服务内发生的事情。
自动容易保留的内容 | 应用端记录的内容 |
|---|---|
Worker 或 Function 的执行 | 询问的受理 |
异常或处理错误 | 会员信息的变更 |
API 的响应 | 权限的变更 |
数据库连接 | 邮件发送处理的成功或失败 |
云环境的管理操作 | 垃圾邮件判断或业务上的拒绝 |
例如，虽然可以知道数据库写入是否成功，但无法区分具体是"接收了咨询"还是"更改了会员信息"。
这类业务事件需要在应用层面进行有意义的记录。
并非所有内容都应该记录到日志中
在为调查做准备时，有时会希望尽可能多地输出信息到日志中。
但是，日志越多并不一定越好。
如果记录所有处理细节，真正需要的信息就会被埋没。日志量增加，存储和搜索的成本也会随之增加。
因此，我们在设计日志时会考虑处理的"边界"。
例如，对于联系表单，
- 提交成功
- 输入内容存在问题，已拒绝
- 被垃圾邮件判定拒绝
- 保存到数据库失败
- 通知邮件发送失败
记录处理结果发生变化的关键点。
不是保留过程中的所有细小变量和处理，而是选择那些之后追踪经过时所需的关键事件。
将日志作为数据而不是文本保存
日志中包含可以后来搜索的信息要比仅仅写"发生了错误"更方便。
项目 | 角色 |
|---|---|
发生时间 | 确认它何时发生 |
事件名称 | 按处理步骤分类 |
优先级 | 区分成功、警告和失败 |
目标 ID | 确定目标数据 |
请求 ID | 追踪一系列处理 |
处理时间 | 检查延迟和性能下降 |
以这种方式按照固定的格式记录这些项目的做法称为结构化日志。
如果按照 JSON 这样的格式整理好项目，就可以轻松进行"仅确认特定申请 ID 相关的处理"、"仅提取出现错误的邮件发送"这样的搜索。
不在日志中写入个人信息
在保留联系表单的日志时，有时会记录姓名、电子邮件地址和查询正文等信息。
这在调查时看起来很方便，但这是一个应该避免的设计方案。
写入日志 | 不写入日志 |
|---|---|
处理日期和时间 | 密码 |
事件名称 | 访问令牌 |
成功/失败 | Cookie |
目标数据的ID | 咨询内容 |
请求 ID | 信用卡信息 |
处理时间 | 不必要的个人信息 |
日志可能会被转发到多个服务或长期保存。如果其中包含个人信息或认证信息，日志本身就会成为新的信息泄露原因。
像咨询内容这样的业务数据应该保存到数据库中，日志中只记录咨询的识别ID和受理成功的事实。
需要时，使用该 ID 与数据库端的信息进行核对。
通过联系表单思考
在咨询表单中，我们经常看到只发送通知邮件的配置。
不过，即使邮件发送处理成功，也不一定能保证送达到收件人。
因此，将查询内容先保存到数据库中，而把电子邮件仅作为对负责人的通知来处理会更加安全可靠。
这样的配置，可以区分"问询本身未送达"还是"问询已保存但通知邮件发送失败"。
正是这些看似细微的差别在实际客服对接中显得尤为重要。
区分短期搜索和长期存储
在日常的故障排查中，能够立即搜索最近的日志是至关重要的。
另一方面，审计和事件调查所需的日志虽然平时很少查看，但在数个月后甚至数年后能够提取出来至关重要。
存储位置 | 主要目的 |
|---|---|
各项服务的日志屏幕 | 最近的操作验证 |
Datadog 等日志管理服务 | 跨域搜索、监控、通知 |
R2 或 S3 | 长期证迹保管 |
将最近的调查所需内容放在易于搜索的位置，并将长期证迹移至低成本存储位置。
虽然看似简单，但这种分类方式在实际工作中效果显著。
日志和仪表板是不同的东西
如果有日志，似乎就能了解访问数、错误率等所有信息。
但是，日志和仪表板中显示的数值在用途上略有不同。
- 日志：详细调查逐条事件
- 指标：汇总件数、比例、处理时间等
- 仪表板：掌握整个系统的趋势
日常状态检查通过仪表板进行，发现异常后再通过日志进行详细调查。
将这两个工具结合使用，就能营造易于运维的状态。
最低限度应该决定的事项
最后，我们汇总一下日志设计中需要确认的项目。
- 要记录的事件
- 日志中包含的项目
- 排除个人信息和认证信息
- 可搜索近期日志的时间范围
- 长期保存日志的范围
- 长期日志的存储位置
- 可查看日志的负责人
- 超过保存期限的日志删除方法
提到审计日志这个词时，您可能会觉得需要记录所有操作，并且必须部署一个庞大的日志管理基础设施。
相反，对于普通网站或媒体网站来说，可以首先确定重要的操作和处理结果，从区分短期搜索和长期保存开始。
关键不是列出正在使用的服务的日志功能，而是要查看整个系统是否保留了必要的记录。
我们留下什么。
为什么要保留它？
需要多长时间?
只要整理好这三个要点，就能避免过度设计，更容易根据项目需求进行日志设计。
日志通常不太引人注意。
但是，当发生问题时是否能够解释"发生了什么"，这在最初的设计中就已经决定了。
这样一步一步打好基础，这是很重要的事情。
那就这样了。
Liberogic 技术部门的中坚力量。一听到「我想要这样的东西，有了就很方便啊」这样的需求，就能凭着聪慧才智加上增值创意，瞬间完成实现。拥有高超的沟通能力，也是我们公司的宝贵人才，在客户中也有很多粉丝，还是个十足的猫咪爱好者。
大塚 翔
执行董事CTO / 首席工程师 / 合同公司猫穴代表 / 看起来不像实际年龄