业务代码异常却日志缺失，如何排查？

业务代码异常，日志却不见了？高效排查指南

开发过程中，业务代码抛出异常，但日志系统却“沉默”的情况时有发生。本文将结合实例，分析可能原因并提供高效的排查策略。

案例代码：

以下代码片段展示了一个嵌套try-catch块的场景：

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”是否真的抛出异常。通过调试模式运行代码，观察异常堆栈信息。如果异常存在，则继续下一步。

2. 检查日志配置：

   • 日志级别： 检查日志配置文件（例如logback.xml或log4j.properties），确保log.error的级别设置为ERROR或更低级别（例如DEBUG）。
   • 输出目标： 验证日志文件路径是否正确，文件是否存在，是否有足够的磁盘空间。检查日志系统是否正确配置，例如是否正确配置了Appender。
   • 日志轮转策略： 检查日志轮转策略是否导致日志文件过早被删除或覆盖。

3. 检查日志系统： 如果日志配置正确，但日志仍然缺失，则可能存在日志系统本身的问题。检查日志系统的运行状态，查看是否有错误日志，尝试重启日志系统。

4. 监控系统： 一些监控系统可以捕获未被日志系统记录的异常。检查监控系统是否有相关告警。

5. 代码审查： 仔细检查“业务代码1”及周围代码，确认异常是否被意外吞没（例如，catch块中没有log.error语句，或catch块中存在return语句）。

6. 异常类型： 某些异常类型可能被JVM或应用服务器自动处理，未记录到日志中。检查JVM或应用服务器的日志，查看是否有相关信息。

通过以上步骤，系统地排查日志缺失问题，并找到根本原因。 记住，先验证异常的存在，再检查日志配置，最后才是日志系统本身。

以上就是业务代码异常却日志缺失，如何排查？的详细内容，更多请关注php中文网其它相关文章！