业务代码异常，日志却不见了？高效排查指南
开发过程中，业务代码抛出异常，但日志系统却“沉默”的情况时有发生。本文将结合实例，分析可能原因并提供高效的排查策略。
案例代码：
以下代码片段展示了一个嵌套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<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或应用服务器的日志，查看是否有相关信息。
通过以上步骤，系统地排查日志缺失问题，并找到根本原因。 记住，先验证异常的存在，再检查日志配置，最后才是日志系统本身。
以上就是业务代码异常却日志缺失，如何排查？的详细内容，更多请关注【创想鸟】其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：PHP中文网，转转请注明出处：https://www.chuangxiangniao.com/p/3246724.html
