java后端debug排查问题思路

问题排查思路

这里说的是主要是debug以及线上问题排查的思路.

解决问题的步骤

确认环境、确定问题、复现问题、查看日志、定位问题 、解决问题

确认环境/url/参数

  • 确认是哪个环境。

是开发环境,测试环境,还是生产环境。

如果问题是在测试环境,去开发环境看问题,不一定能复现。

如果采用了微服务架构,还要查看注册中心,服务是否生效,启用了哪一个实例。

  • 哪个接口?哪些参数?哪个时间段?

确认url是否正确,参数有没有传错了。

确定问题

有时候测试/用户提出的问题,不一定是bug。

一定要跟需求做校对,确认是否与需求一致,是否因需求不合理导致的。

复现问题

问清楚测试/用户,问题是如何出现的,具体的操作步骤是什么,查看是否因为操作步骤不正确导致的。

在相同的环境,自己重新操作一遍,复现问题。

如果无法复现,问清楚出错的操作时间,直接查看日志。

如果无法确定逻辑,可以问产品,问测试。
如果无法确定是哪个接口,哪个字段,可以问前端。

查看日志

生产环境中,是没法进行debug的,所以日志非常重要。
开发中,一定要把重要的变量打印出来。
打印日志, 非常有利于解决问题。

  • 链路追踪
    如果项目使用了微服务架构,最好有相应的链路追踪中间件,比如 SkyWalking。
    traceId,用于标识一次请求的ID。在同一个请求调用过的服务模块中,traceId都是相同的。
    可以通过traceId不断地追踪。

从上往下追踪,A服务调用B服务,先去A服务看下日志,找出 traceId,然后去B服务根据 traceId 继续追踪。

如果没有 SkyWalking, 也可以看下打印的日志有没有带上线程 id,可以根据线程id去跟踪。
在日志比较多的情况下,根据线程id找出请求相关的日志,方便定位问题。

  • 异常错误
    如果是异常错误,直接查看error日志中在堆栈信息,找到出错在代码就可以了。

  • 逻辑错误
    查看info/debug日志中的信息。
    如果关键的信息没有打印日志,那么补充日志后,重新发布到开发/测试环境中。
    在解决问题时,补充日志,重新发布环境,是非常有效的方法。 虽然土,但是有用。
    绝大部分逻辑问题,都可以通过打印日志解决。

  • 复制数据到本地环境调试
    如果是在生产环境,可以把日志打印出来,如果是对象,可以打印成json字符串,本地环境再转换成对象。
    通过复制数据到本地环境,进行调试。

查询数据源

将查询或更新的sql或es等语句找出来,在对应的数据源中查询进行定位。

可以用下 MyBatis Log Free 插件: (免费)显示Mybatis的Sql。一下子把sql打印出来。
可以说是开发必须的插件了,遇到问题,马上打印sql,能快速定位问题。

定位问题

数据的流程一般是: 数据源产生数据—>加工数据—>目标变量获取数据

如果数据有问题,那么就要从这三方面分析,是在哪一步出错了。

是数据源的数据本来就不对,或者数据在加工过程中出错了,还是目标变量取错了数据,数据出错 ?

IDEA查看变量的调用链,可以参考以下文章:
https://www.cnblogs.com/expiator/p/10856482.html

解决问题

修改代码后,重新发布环境,查看问题是否已经解决。

结语

实际中遇到的问题,可能会更加复杂,还是需要多思考,多分析,多解决实际问题。

无他,唯手熟尔。

你可能感兴趣的:(A1-系统设计,项目管理,工作实践/效率,java,后端)