业务代码异常，日志却不见了？高效排查指南
开发过程中，业务代码抛出异常，但日志系统却“沉默”的情况时有发生。本文将结合实例，分析可能原因并提供高效的排查策略。
案例代码：
try { List<Plan> plans = planService.lambdaQuery() .eq(Plan::getYn, YnEnum.YES.getLabel()) .eq(Plan::getStatus, Plan.Status.DONE.getCode()) .isNotNull(Plan::getPId) .list(); List<List<Plan>> partition = Lists.partition(plans, 5); partition.forEach(planList -> { try { // 业务代码1 (潜在异常点) } catch (Exception exception) { log.Error("报错信息1：", exception); // 内层异常捕获 } }); } catch (Exception exception) { log.error("报错信息2：", exception); // 外层异常捕获 } finally { log.info("释放requestId[{}]的锁", requestId); Redis.unlock(Module.REFRESH_PROMOTE, workerLockKey, requestId); }
问题： “业务代码1”可能抛出异常，但“报错信息1”日志缺失。
分析：
代码采用双层try-catch结构。如果“业务代码1”抛出异常，内层catch块捕获并记录“报错信息1”。 如果内层catch处理异常后程序继续执行，外层catch不会执行，导致“报错信息2”也不输出。因此，日志缺失可能源于日志记录配置问题。例如：
- 日志级别设置过高： 日志系统可能只记录ERROR级别以上日志，而log.error的实际级别被配置为WARN或INFO。
- 日志输出目标错误： 日志文件路径配置错误，或日志系统无法写入目标文件。
- 日志系统故障： 日志系统本身出现问题，导致日志无法记录。
排查步骤：
-
验证异常是否存在： 首先，务必确认“业务代码1”是否真的抛出异常。通过调试模式运行代码，观察异常堆栈信息。如果异常存在，则继续下一步。
-
检查日志配置：
-
检查日志系统： 如果日志配置正确，但日志仍然缺失，则可能存在日志系统本身的问题。检查日志系统的运行状态，查看是否有错误日志，尝试重启日志系统。
-
监控系统： 一些监控系统可以捕获未被日志系统记录的异常。检查监控系统是否有相关告警。
-
代码审查： 仔细检查“业务代码1”及周围代码，确认异常是否被意外吞没（例如，catch块中没有log.error语句，或catch块中存在return语句）。
-
异常类型： 某些异常类型可能被jvm或应用服务器自动处理，未记录到日志中。检查JVM或应用服务器的日志，查看是否有相关信息。
通过以上步骤，系统地排查日志缺失问题，并找到根本原因。 记住，先验证异常的存在，再检查日志配置，最后才是日志系统本身。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
