阿里妹导读
一. 写在前面
由于闲鱼没有日常环境,开发的调试,项目联调,测试验证等流程都集中在预发环境进行,所以预发环境问题会集中爆发。
面对大量爆发的问题,我们依靠之前已有的闲鱼全链路日志查询平台能力,可以实现异常日志的定时扫描+统计,提供了我们快速发现问题的能力。
之前,我们处理扫描出来的异常问题,需要测试先过滤一遍异常,然后指派给一个指定的开发owner(一个应用对应一个开发owner),然后由开发owner 自己去看代码识别 判断指派的问题是不是自己写的,如果不是,需要转发给其他开发,这里面会涉及到测试+开发两方面的精力投入,如果BUG很多的情况下,开发和测试都会有相当大的成本。我们之前实践下来确实会存在效率相对较低的情况(往往开发自己排查的成本相对较大,毕竟需要一个个的去翻代码)。
针对这种情况,我们研发了一套异常日志问题自动追踪-定位-分发机制,帮助0成本的找到测试环境/线上环境 BUG的制造人,自动分发缺陷给到对应开发,同时我们指派的BUG可以精确到行级别(哪一行日志报错,自动指派给那一行的提交人),做到又准又快又省力。
以后,谁写的BUG,一个也别想跑(颤抖吧,开发们~~~)
二. 功能实现
示意图:
下面介绍一下如何自动追踪定位BUG:
1. 过滤异常堆栈信息
当我们日志扫描到异常问题时,我们会记录下异常的日志内容数据,如下图所示:
第一步我们会通过正则匹配过滤出异常数据信息:
正则的规则是通过堆栈报错的典型关键词 at ,每一个at 后的异常代码行数据实际就是一个错误溯源路径,路径中携带了代码类信息和报错的具体代码行信息,我们会将这部分数据批量获取。
2. 获取异常代码行
at com.alibaba.xxx.xxx.xxxxx.xxx.xxx.xxxxxxxx.updatexxxx(AXXXXXXX.java:447)
以上面为例,异常的代码行信息:AXXXXXXX.java:447
如1中所述,每一个异常的代码行信息包含:类的全路径信息和报错的具体代码行信息。
我们继续通过正则匹配,拿到这部分数据中的两个核心信息:报错类名称 AXXXXXXX和报错代码行447 ,这样一个异常代码行的数据就提取完成。
之后我们依次循环,最终针对每一个异常日志堆栈,我们会提取出5个异常代码行队列数据。
至于为什么是5个,因为我们在实际判断过程中,前面的异常点位不一定是业务代码引入的,例如一些线类转换异常的报错点位,其实不是开发提交代码导致的,但是再往后的调用处报错,才是开发引入的,所以,我们需要往后继续排查,才能找到问题所在。
故我们做了一定的配置化,可以控制查找的点位数量,循环的尝试异常代码行队列,直到查询到有效值数据。
3. 获取目标分支信息branch
预发环境存在多个分支,我们想定位问题和人的前提是必须拿到对应目标分支的数据,才能进一步去判断异常的位置。
另外,预发日志打印出来的报错,都是基于当前部署分支进行打印的,所以打印出来的异常代码行信息也是基于部署分支,故我们必须要获取当前应用在我们日志扫描期间,存在于预发环境的部署分支信息,同时也要将master分支作为备份,因为有时候问题不在部署分支上,我们需要再以master分支进行兜底查询。
4. 获取Git文件路径file_path
通过 应用对应的 仓库ID +分支信息branch+ 异常代码类信息 AXXXXXXX.java +认证授权信息 。
可以拿到 异常的 AXXXXXXX.java类 对应的 GIt 文件路径地址信息 file_path,只要获取到代码路径信息,才能拿到具体的代码文件源数据信息,所以这个 file_path 对我们后面查明“真凶” 至关重要。
5. 获取异常代码git提交行的人
从2中,我们还可以拿到具体的代码行line , 我们通过具体的对应的仓库ID + GIt 文件路径地址信息file_path+具体的异常代码行line +认证授权信息 ,可以拿到对应git 代码的提交人信息。
最后,我们可以看到 对应开发提交这行 AXXXXXXX.java:447 代码的时间,开发可以自行检查是否符合,是否是自己提交的代码,然后麻溜的赶紧修复掉问题!!!
三. 写在最后
在S2,我们会在每周一次自动分发异常问题精准的给到对应开发同学,同时为了过滤噪音,也会针对特定类型的日志异常做过滤,支持配置,让每一个分发到开发同学手中的BUG都是有修复价值的。
最终我们会形成两份针对应用维度和人维度的异常问题修复统计表,能够清晰的让大家看到异常问题修复进度。
我们衷心期望:所有的异常问题都能消灭在预发环境,不让一个小问题遗留到线上!!
如何让你的AI大模型开启“外挂”之旅?
面向需要高效文档管理与解析、有精细化内容分析与洞察需求的企业,通过将文档智能和检索增强生成(RAG)结合起来构建强大的LLM知识库,包括清洗文档内容、文档内容向量化、问答内容召回后通过特定的Prompt,提供给LLM足够的上下文信息,以此来满足对于企业级文档类型知识库的问答处理。
点击阅读原文查看详情。