服务端日志Server Logs

你可能会说

线上报错了，我想知道服务器那边到底发生了什么，去哪看？

记录后端运行时发生了什么，主要用来查找失败原因例如用户提交订单时出现服务器错误；如果记录了关键步骤，日志可以帮助判断是保存数据还是检查权限出了问题。日志要保留时间和必要线索，但不能记录密码、登录凭证或完整个人资料。
先知道
后端 Backend终端命令行 Terminal
服务端日志req_8fa2
12:08:31收到请求POST /api/orders12:08:31订单已写入order=o_91184ms返回成功201
同一个 request id 串起一次请求

什么时候用

  • 记录时间、级别、请求 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
说明何时发生、是普通信息、警告还是错误
把同一次请求产生的多行日志串在一起，方便跨步骤追踪
记录动作、结果、耗时和必要标识，但不写密码、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%告警已通知