業務代碼異常卻日志缺失，如何排查？

業務代碼異常，日志卻不見了？高效排查指南

開發過程中，業務代碼拋出異常，但日志系統卻“沉默”的情況時有發生。本文將結合實例，分析可能原因并提供高效的排查策略。

案例代碼：

以下代碼片段展示了一個嵌套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或應用服務器的日志，查看是否有相關信息。

通過以上步驟，系統地排查日志缺失問題，并找到根本原因。 記住，先驗證異常的存在，再檢查日志配置，最后才是日志系統本身。