日志常被当作出问题后才看的文件。实际上，日志设计决定了团队能否回答四类问题：谁访问了什么，哪里报错了，表单是否提交成功，最近谁改了配置。没有结构的日志既占空间，也无法帮助判断。
访问日志回答入口问题
访问日志应包含时间、路径、状态码、来源 IP、用户代理、响应时间和必要的来源信息。它可以帮助判断是否存在异常扫描、某地区访问失败、旧链接大量 404 或某资源流量突然增长。
错误日志回答系统问题
错误日志应尽量包含错误类型、关联请求、服务名称和发生时间，但不应泄露密码、私钥或完整个人数据。对于 Node 服务、反向代理、数据库和第三方接口，日志位置要写在运维文档里。
表单日志回答业务问题
表单提交是否进入数据库、验证码失败是否异常、邮件通知是否发送成功，这些都需要记录。否则客户说“我提交了但没人回复”时，团队无法判断是用户未提交、验证码失败、邮件丢失还是内部处理遗漏。
| 日志类型 | 主要用途 | 保留建议 |
|---|---|---|
| 访问日志 | 流量、状态码、来源 | 按容量滚动保留 |
| 错误日志 | 故障定位、依赖异常 | 结合发布周期保留 |
| 表单日志 | 线索确认、垃圾提交 | 按隐私政策保留 |
| 变更记录 | 发布、配置、权限 | 长期保留摘要 |
日志保留要考虑隐私和成本
日志可能包含 IP、路径、表单字段和内部操作信息，不应无限期保存。合理做法是分级保留：短期保留详细日志，长期保留摘要和关键变更记录。这样既能排查问题，也能减少不必要的数据风险。