我用AI做了个问题排查工具

负责在线业务的都知道，经常24小时OnCall，很多时候要配合排查问题，比如为什么某个人没返回广告，这时候就需要根据一些信息去查询这个人的信息，然后拿着信息去线上服务查日志，根据日志信息去分析，最终给出结论；要么就是某个在线服务突然崩溃了，这时候就需要拿着堆栈信息或者系统日志去进行分析，这种往往很费时费力，经常做着重复性工作。

基于以上，最近做了个问题排查工具。

工具的功能很简单，选好服务，填一个请求 ID，再写上“为什么接口返回空结果”，它会去测试环境查日志，然后结合源码给出分析。手里已经有日志、响应 JSON 或崩溃堆栈的话，也可以直接粘贴进去。

做它的原因很简单，每次查问题，都要找日志、复制字段、搜索代码这些操作，这些步骤都要重复一遍。

尤其是“接口返回空结果”这类问题。响应里可能只有一个状态码，但代码里能返回这个状态码的地方有好几个。要判断走了哪条路径，还得看请求参数、配置和开关状态。有时搜到一条下游服务返回空的日志，继续往后看，才发现它和最终结果并没有直接关系。

所以，想把前面几步省掉，日志在哪里、服务代码在哪个目录，先配置好；拿到请求以后，让 AI 从错误码和关键字段开始查代码，把找到的位置和判断理由一起列出来。人再接着核对。

图 1：网页后面主要是一个 Node 服务，负责查日志和启动分析进程。

实现比较直接。页面放在已有的平台里，复用登录和权限。后面单独起一个 Node 服务，接收用户的问题，按配置找到代码目录和测试日志节点。请求 ID 查询通过 SSH 执行读取脚本，拿到日志后，再启动 Codex 分析。

服务和目录是一一配置的。选了哪个服务，就从对应目录开始找；测试节点和日志路径也由后端决定。页面不用接收服务器地址，更不用让用户自己拼查询命令。

调用 Codex 时，日志和问题从标准输入传进去，使用只读沙箱执行。它可以搜索代码、查看实现，但不能修改文件。分析要求也写得很具体：从这次日志里的线索出发，找到相关条件；需要引用代码就带上文件位置；缺少配置或下游日志，就说明还需要补什么。

真正跑起来以后，有几个细节花了不少功夫。

第一个是查日志的范围。按请求 ID 搜到结果，看起来就像“这次请求的日志已经拿全了”。实际上，process.log 里只有带这个 ID 的命中行，有些上下文在相邻几行里，有些还在别的服务。把这些片段直接交给模型，它很容易据此往下推。

现在查询结果里会一起带上检索说明：查的是哪个测试节点、哪个时间段，返回了多少请求记录和过程片段，扫描有没有完成。页面能看到这些信息，模型也会收到。没查到下游日志的地方，分析里就要留出来，不能补成一段看似完整的调用过程。

日志文件本身也有取舍。只读文件末尾一段，可能漏掉前面的请求；把所有文件都扫一遍，遇到大日志又可能等很久。目前先按轮转时间筛选候选文件，再在扫描量和时间限制内读取。达到限制就停，并说明哪些文件没查完。

还有业务 ID 的精度问题。日志里的长整数一旦被 JavaScript 当作普通数字解析，尾数就可能变掉。原本想查同一条记录，传了一遍之后，ID 已经不是原来的 ID 了。所以命中的请求 JSON 保留为原始字符串，格式化只处理空白，后面转发时也尽量保持原文。

图 2：排队、查日志和读代码都需要时间，页面会显示当前进行到哪一步。

等待体验也得处理。分析过程中，页面会陆续显示“正在查日志”“正在排队”“正在检索代码”。后端用逐行 JSON 返回这些事件，前端收到完整的一行再解析。一个网络数据块可能只有半条事件，甚至截在一个中文字中间，这些情况都得接住。

模型中途写出的几段话，我没有直接放到结果区。它查到一半可能还会改变判断。等分析进程正常结束，收到完成事件，再把最后的答案显示出来。使用者等待时看得到进度，复制结果时拿到的是完整的一次分析。

“停止”按钮也要管到后台。用户停止分析、关掉页面或请求超时后，要取消排队、结束远程查询，或者终止对应的模型进程。否则页面虽然不等了，后台还在继续跑。并发名额也要在这些路径上释放，后面的请求才能接着执行。

有一次完整测试，查的是一个返回空结果的请求。工具取到了 1 条请求记录和 2 条过程日志命中行，从响应状态找到源码，再结合请求参数，找到了一个提前返回的分支。那次从查日志到出结果，大约花了一分半钟。

图 3：这次测试的简化示意。字段已改成演示名称，代码是伪代码。

这个结果把接下来要查的地方缩小了：请求参数为什么会触发这个条件，相关开关现在是什么值，以及测试环境部署的是不是正在看的这份代码。拿着文件位置和日志字段，就可以继续核对。

但那几条日志没法回答所有问题。比如各个下游服务到底返回了什么，这次没有查到。工具现在也不会自动核对部署版本，这一步还得人来做。如果把“当前代码里有这个分支”直接写成“线上一定执行了这个分支”，这个分析就过头了。

还有个问题就是，当前需要选择服务，然后输入日志等信息才会进行排查，后面准备让其自动选择服务，获取对应的日志。

最最大的一个问题是，使用的我自己的token，任何人想查问题都是用我的token，这个后面还是要解决的。

如果对本文有疑问可以加笔者微信直接交流，笔者也建了C/C++相关的技术群，有兴趣的可以联系笔者加群。