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

业务代码异常，但日志消失了？高效调查指南

在开发过程中，业务代码出现异常，但日志系统经常“沉默”。本文将分析可能的原因，并结合实例提供有效的故障排除策略。

案例代码：

以下代码片段展示了嵌套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.WARN或INFO配置了error的实际级别。
• 日志输出目标错误： 日志文件路径配置错误，或者日志系统无法写入目标文件。
• 日志系统故障： 日志系统本身存在问题，导致日志无法记录。

排查步骤：

1. 验证异常是否存在： 首先，一定要确认“业务代码1”是否真的抛出异常。通过调试模式操作代码，观察异常堆栈信息。如有异常，请继续下一步。

2. 检查日志配置：

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

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

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

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

6. 异常类型： JVM或应用程序服务器可以自动处理一些异常类型，而不记录在日志中。检查JVM或应用程序服务器的日志，查看是否有相关信息。

通过以上步骤，对日志缺失问题进行系统调查，找出根本原因。 记住，先验证异常存在，再检查日志配置，最后是日志系统本身。

以上是业务代码异常但缺乏日志，如何调查？详情请关注图灵教育的其他相关文章！