系统出了问题但日志没有记录时，如何排查？

核心回答

先确认“没有记录”是应用没有产生日志、日志在输出或采集链路中丢了，还是查询范围和关联方式不对。没有错误日志不能证明没有故障；排查要从用户现象、时间范围和受影响请求建立事实，再结合指标、调用链、系统状态和业务数据缩小范围。

对 AI 系统还要区分程序异常和结果质量错误：模型输出了错误答案，调用可能仍然成功并返回 200，自然不会出现异常堆栈。

先检查日志链路

核对时区、时间窗口、实例、容器和服务版本，确认请求是否进入预期入口。查看源文件或标准输出是否有记录，再检查日志级别、过滤规则、采样、异步队列、轮转、磁盘及采集器权限和积压。

若源端有而平台没有，重点排查采集、解析、传输与索引；若源端也没有，检查代码分支是否执行、异常是否被吞、进程是否在缓冲落盘前崩溃。不要因为搜索关键词没命中，就立即判断业务未执行。

没有日志时还能用什么证据

• 从入口流量、错误率和延迟判断故障范围，结合发布、配置和依赖变更时间寻找关联。
• 通过 Trace、网关记录、数据库慢查询/锁等待、消息位点、任务状态及第三方调用记录重建已发生的步骤。
• 对当前进程查看线程栈、CPU、内存、GC、连接池和队列，判断阻塞、死锁或资源耗尽；必要时使用有范围和时限的运行时诊断。
• 在可控环境用相同输入和配置复现，逐步验证假设；一次观察不能直接推出历史故障的唯一根因。

对应教程第 17 章展示了并发请求中用 request_id 串联日志的作用，排查时也要检查异步上下文是否正确传播。

AI 可以帮助什么

AI 可以整理现有证据、生成排查假设、检索历史案例和建议下一步观测，但不能从不存在的日志里恢复确定事实。Agent 排障需要通过工具读取指标、Trace、配置或运行时信息，并标明观测与推断；如果关键证据已丢失，应保留不确定结论。

修复后补充关键状态迁移、异常边界、任务/请求关联及日志管道自身监控。对模型问题记录必要的模型、Prompt版本、检索标识和工具结果摘要，并建立质量评测；同时控制敏感内容、成本与保留期，避免靠无限增加全文日志解决所有问题。

参考资料