服务端日志
Server Logs
中级通用服务端日志（Server Logs）是服务运行时记录的请求、错误和处理过程等信息。你可以用它还原服务器上发生了什么，排查用户看到报错、但自己无法复现的问题。
你可能会说：「网站上线后有人说提交表单会报错，我想知道服务器当时到底发生了什么。」
读之前建议先了解
动手看看下单失败的日志追踪
订单服务 · 日志追踪
模拟记录
POST /orders · req-8f2
用户看到：暂时无法下单，请稍后重试（HTTP 503）
服务端记录 · 按时间升序
14:32:10.002 INFO[req-8f2] 收到下单请求，商品 SKU-42，数量 1
14:32:10.008 INFO[req-8f2] 开始查询库存，调用 inventory-service
14:32:12.009 ERROR[req-8f2] 库存查询超时：InventoryTimeout，耗时 2001ms
14:32:12.012 WARN[req-8f2] 中止创建订单，向客户端返回 503
模拟下单结果
只看请求 req-8f2
日志级别
这是模拟的下单记录，不会发送真实请求。切换下单结果、请求筛选和日志级别；悬停或用 Tab 聚焦日志行，沿时间往下看。
用户只看到无法下单，服务端却记录了收到请求、查询库存、超时和返回 503。故障点在库存查询，但超时的底层原因还要继续查。
要点服务端日志能帮你看清什么？
- 1
记录服务处理时发生的事
用户提交表单后，浏览器只知道请求失败了；服务端日志可能留下请求到达的时间、处理到哪一步，以及哪里抛出了错误。这样我们能从服务器一侧找原因。
- 2
用线索定位同一次请求
排查时，你可以先确认出错时间和运行环境，再结合接口路径、错误信息或请求 ID 缩小范围。因为同一时刻可能有很多请求，只盯着一行报错容易看错对象。
- 3
记录有用信息但避开敏感内容
日志里有足够的上下文，排错才快；但密码、访问令牌和完整个人资料一旦写进去，也可能被更多人看到。所以我们通常记录必要的状态和标识，避免直接记下敏感原文。
容易混淆的地方
服务端日志是一次次事件留下的记录；监控通常把指标和告警汇总起来，先告诉你服务是否异常，再帮你决定去哪查日志。审计日志则侧重记录谁在何时做了什么重要操作，方便追溯责任；普通排错日志不一定能承担这个用途。
什么时候用
适合用
- 网站上线后部分用户提交订单失败，你想按出错时间查服务处理到了哪一步。
- AI 工具偶尔返回错误，你想区分是自己的服务报错，还是调用外部模型时失败。
- 新版本部署后接口开始报错，你想对照报错记录判断受影响的请求。
不适合用
- 只是想知道按钮点击后页面为什么没变化，先用浏览器开发者工具检查前端报错和网络请求。
- 想统计多少用户看过定价页、点过购买按钮，用事件埋点来分析行为，而不是靠服务端日志计数。
- 要追溯后台管理员修改了谁的权限，使用专门的审计日志记录操作人、对象和结果。
练一练选一个答案，看看解释
用户说昨晚在 App 里提交资料时看到“保存失败”，但你今天测试正常。你会先让 AI Agent 怎么查？
让 AI 帮你做复制给 AI Agent 直接用
请帮我排查昨晚 App 提交资料时出现的“保存失败”。先确认运行环境、出错时段和对应接口，再查看服务端日志，按请求 ID 或其他可用线索关联记录。说明你找到的证据和仍不确定的地方；不要在输出中暴露令牌或个人资料。