业务代码异常，日志却不见了？高效排查指南
开发过程中，业务代码抛出异常，但日志系统却“沉默”的情况时有发生。本文将结合实例，分析可能原因并提供高效的排查策略。
案例代码：
以下代码片段展示了一个嵌套try-catch块的场景：
try {
List plans = planService.lambdaQuery()
.eq(Plan::getYn, YnEnum.YES.getLabel())
.eq(Plan::getStatus, Plan.Status.DONE.getCode())
.isNotNull(Plan::getPId)
.list();
List> 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”是否真的抛出异常。通过调试模式运行代码，观察异常堆栈信息。如果异常存在，则继续下一步。
-
检查日志配置：
-
日志级别： 检查日志配置文件（例如
logback.xml或log4j.properties），确保log.error的级别设置为ERROR或更低级别（例如DEBUG）。 - 输出目标： 验证日志文件路径是否正确，文件是否存在，是否有足够的磁盘空间。检查日志系统是否正确配置，例如是否正确配置了Appender。
- 日志轮转策略： 检查日志轮转策略是否导致日志文件过早被删除或覆盖。
-
日志级别： 检查日志配置文件（例如
-
检查日志系统： 如果日志配置正确，但日志仍然缺失，则可能存在日志系统本身的问题。检查日志系统的运行状态，查看是否有错误日志，尝试重启日志系统。
-
监控系统： 一些监控系统可以捕获未被日志系统记录的异常。检查监控系统是否有相关告警。
-
代码审查： 仔细检查“业务代码1”及周围代码，确认异常是否被意外吞没（例如，
catch块中没有log.error语句，或catch块中存在return语句）。 -
异常类型： 某些异常类型可能被JVM或应用服务器自动处理，未记录到日志中。检查JVM或应用服务器的日志，查看是否有相关信息。
通过以上步骤，系统地排查日志缺失问题，并找到根本原因。 记住，先验证异常的存在，再检查日志配置，最后才是日志系统本身。
