服务端日志Server Logs

上线与排错

查看后端收到请求后发生了什么

先知道

服务端日志记录请求、关键步骤、警告和错误，是线上排错的重要入口。日志要保留足够上下文帮助定位，同时避免写入密码、Token、Cookie 等敏感信息，以及完整的个人资料。

12:08:31 POST /api/orders req_8fa2INFO order created · 201 · 184msuser=u_23 · order=o_91

记录时间、级别、请求 id、动作、结果和耗时

一条可定位的日志

12:08:31 INFO req_8fa2POST /api/orders · 201 · 184ms
错误日志保留堆栈和必要上下文，用户响应保持简洁

用户和开发者看到不同层次

页面提示暂时无法保存，请重试服务端日志DB timeout · stack trace
部署后先复现一次，再按时间或 request id 搜索日志

用 request id 串起一次请求

req_8fa2 · request receivedreq_8fa2 · payment checkedreq_8fa2 · order created
对错误率、延迟和关键失败设置监控与告警

从单条日志上升到监控

过去 5 分钟错误率 8.2%告警已通知值班人员

打印密码、Token、Cookie 或整份用户资料

日志中不能记录敏感信息

password=123456token=eyJhbGciOi••••cookie=session=••••
只写“出错了”：没有动作、对象和错误原因

这条日志无法帮助排错

16:42:09 ERROR 出错了缺少请求、动作、对象和原因
用日志代替错误处理：打印后仍假装请求成功

打印错误后仍返回成功

数据库失败→console.error→200 OK

日志不能代替重试、回滚或失败响应
线上开启海量调试日志又从不清理，成本和噪音一起涨

调试日志淹没真正的问题

每天1,280 万行 DEBUG真正错误3 行，被噪音盖住

组成结构 · Anatomy

12:08:31 · INFOreq_8fa2order created · 184ms

1时间与级别Time & Level说明何时发生、是普通信息、警告还是错误

2请求编号Request ID把同一次请求产生的多行日志串在一起，方便跨步骤追踪

3事件与上下文Event记录动作、结果、耗时和必要标识，但不写密码、Token 或完整个人资料

常见变体 · Variants

INFOINFO

请求完成 · 201

记录正常的关键业务动作

WARNWARN

重试第 2 次

暂未失败，但需要关注

ERRORERROR

数据库连接失败

请求失败，需要定位和告警

典型使用场景

Vercel Function Logs

函数日志查看一次请求发生了什么

12:08:31 INFO req_8fa2POST /api/ordersorder created · 201 · 184ms

按 request id 追踪请求

请求追踪用同一个 request id 串起多步

req_8fa2 · request receivedreq_8fa2 · payment checkedreq_8fa2 · order savedreq_8fa2 · response 201

查看 500 错误堆栈

500 错误用户看到简短提示，日志保留细节

页面暂时无法保存，请重试日志DB timeout · stack line 42

监控错误率与响应耗时

运行监控从日志汇总错误率和耗时

请求量12.4kP95 延迟820ms错误率8.2%告警已通知