为什么要做：要0成本的发现问题---> 定位问题 ---> 帮助开发加速解决问题。

由于闲鱼没有日常环境，开发的调试，项目联调，测试验证等流程都集中在预发环境进行，所以预发环境问题会集中爆发。

面对大量爆发的问题，我们依靠之前已有的闲鱼全链路日志查询平台能力，可以实现异常日志的定时扫描+统计，提供了我们快速发现问题的能力。

之前，我们处理扫描出来的异常问题，需要测试先过滤一遍异常，然后指派给一个指定的开发owner（一个应用对应一个开发owner），然后由开发owner 自己去看代码识别 判断指派的问题是不是自己写的，如果不是，需要转发给其他开发，这里面会涉及到测试+开发两方面的精力投入，如果BUG很多的情况下，开发和测试都会有相当大的成本。我们之前实践下来确实会存在效率相对较低的情况（往往开发自己排查的成本相对较大，毕竟需要一个个的去翻代码）。

针对这种情况，我们研发了一套异常日志问题自动追踪-定位-分发机制，帮助0成本的找到测试环境/线上环境 BUG的制造人，自动分发缺陷给到对应开发，同时我们指派的BUG可以精确到行级别（哪一行日志报错，自动指派给那一行的提交人），做到又准又快又省力。

以后，谁写的BUG，一个也别想跑（颤抖吧，开发们~~~）

示意图：

下面介绍一下如何自动追踪定位BUG：

当我们日志扫描到异常问题时，我们会记录下异常的日志内容数据，如下图所示：

第一步我们会通过正则匹配过滤出异常数据信息：

正则的规则是通过堆栈报错的典型关键词 at ，每一个at 后的异常代码行数据实际就是一个错误溯源路径，路径中携带了代码类信息和报错的具体代码行信息，我们会将这部分数据批量获取。

at com.alibaba.xxx.xxx.xxxxx.xxx.xxx.xxxxxxxx.updatexxxx(AXXXXXXX.java:447)  

以上面为例，异常的代码行信息：AXXXXXXX.java:447

如1中所述，每一个异常的代码行信息包含：类的全路径信息和报错的具体代码行信息。

我们继续通过正则匹配，拿到这部分数据中的两个核心信息：报错类名称 AXXXXXXX和报错代码行447 ，这样一个异常代码行的数据就提取完成。

之后我们依次循环，最终针对每一个异常日志堆栈，我们会提取出5个异常代码行队列数据。

至于为什么是5个，因为我们在实际判断过程中，前面的异常点位不一定是业务代码引入的，例如一些线类转换异常的报错点位，其实不是开发提交代码导致的，但是再往后的调用处报错，才是开发引入的，所以，我们需要往后继续排查，才能找到问题所在。

故我们做了一定的配置化，可以控制查找的点位数量，循环的尝试异常代码行队列，直到查询到有效值数据。

预发环境存在多个分支，我们想定位问题和人的前提是必须拿到对应目标分支的数据，才能进一步去判断异常的位置。

另外，预发日志打印出来的报错，都是基于当前部署分支进行打印的，所以打印出来的异常代码行信息也是基于部署分支，故我们必须要获取当前应用在我们日志扫描期间，存在于预发环境的部署分支信息，同时也要将master分支作为备份，因为有时候问题不在部署分支上，我们需要再以master分支进行兜底查询。

通过 应用对应的 仓库ID +分支信息branch+ 异常代码类信息 AXXXXXXX.java +认证授权信息 。

可以拿到 异常的 AXXXXXXX.java类 对应的 GIt 文件路径地址信息 file_path，只要获取到代码路径信息，才能拿到具体的代码文件源数据信息，所以这个 file_path 对我们后面查明“真凶” 至关重要。

从2中，我们还可以拿到具体的代码行line , 我们通过具体的对应的仓库ID + GIt 文件路径地址信息file_path+具体的异常代码行line +认证授权信息 ，可以拿到对应git 代码的提交人信息。

最后，我们可以看到 对应开发提交这行 AXXXXXXX.java:447 代码的时间，开发可以自行检查是否符合，是否是自己提交的代码，然后麻溜的赶紧修复掉问题！！！

在S2，我们会在每周一次自动分发异常问题精准的给到对应开发同学，同时为了过滤噪音，也会针对特定类型的日志异常做过滤，支持配置，让每一个分发到开发同学手中的BUG都是有修复价值的。

最终我们会形成两份针对应用维度和人维度的异常问题修复统计表，能够清晰的让大家看到异常问题修复进度。

我们衷心期望：所有的异常问题都能消灭在预发环境，不让一个小问题遗留到线上！！