背景
- 在大家测试联调的过程中,以及线上bug的排查中,有的人喜欢根据报错直接取排查代码,这样导致治标不治本,即只能定位当前问题,诶有办法确定问题的根源,导致项目中依然存在其他的隐患
排查问题的步骤
- 首先通过自测或者用户反馈,暴露出系统的问题
- 当运营或者开发收到问题反馈的时候,联系问题提出人提供参数进行复现,当可以稳定复现的时候,说明是必有缺陷,如果不能稳定复现,在下文说明
- 当可以稳定复现的时候,可以通过参数进行debug,日志,以及返回提示快速定位问题
- 确定问题之后,解决问题
- 解决问题之后联系问题提出人进行验证
- 以上就是公认的排查问题的通常步骤
不能稳定复现的场景
- 在实际生产环境中,有时会出现不能稳定复现的以下场景
- 部分用户的存在问题
- 只有某些时刻存在问题
- 刚才有问题,现在没问题
- 只有某些机器有问题,其他机器没问题
小结
- 以上的列出的场景,虽然体现出系统的缺陷性,但是对于排查成本是极高的,在实际生产中,除非是核心的业务,基本上大家是忽略的
- 接下来会针对不能稳定复现的场景进行整理和思考,提出一般性的解决方式
不能稳定复现-排查成本高的原因
- 由于分布式的服务,请求链路长,日志分散
- 由于系统的qps比较高,打的日志特别多,找起来费事
- 由于代码里没有使用try-catch异常捕获,导致被全部异常拦截器捕获,异常堆栈不全
- 问题提出人无法提供有效的复现参数,导致无法定位日志
解决方案
- elk日志系统
- 代码返回增加异常捕获
不能稳定复现-场景和可能的原因
场景 | 原因 | 解决方案 | 备注 |
部分用户的存在问题 | 通常是数据问题 | 修复数据库的数据 | |
只有某些时刻存在问题 | 通常是链路问题,如scf调用量过大,被抛弃 | 提升调用量,排查调用链路 | |
只有某些机器有问题,其他机器没问题 | 通常是缓存问题,如不安全的容器类 | 排查代码里使用的缓存类 | |
最坏的情况-马上就要定位,来不及加日志了
- 推荐使用arhtas ,Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。 https://arthas.aliyun.com/doc/#
- 针对这种场景可以使用watch命令和throwExp参数,以及-e
watch com.xxx.web.controller.XXXXController xxxMethod {params,returnObj,throwExp} -e -x 6参数说明
- watch命令可以查看返回值和入参
- throwExp 等于 Exception对象
- -e 表示只有在异常的时候才会输出,减少数据量
总结
- 复现对于解决问题,相当于debug对于开发,是事半功倍的利器
- 准确的掌握复现的工具使用,可以极大的提升问题的解决质量和解决效率
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
