在現代軟體開發的快節奏環境中，有效的日誌記錄對於高效的調試和系統監控至關重要。但是，日誌輸出中不一致或不準確的行號可能會使故障排除變得非常耗時。最近，我發現我們的內部日誌記錄實用程式將自身報告為日誌來源。需要解決這個問題以提高日誌精確度。

問題

當使用自訂實用程式類別來處理日誌時，它將開始將自身報告為日誌來源，因為實用程式類別是最終呼叫實際日誌框架的類別（在我的例子中，它是SLF4J ，以Log4J2為後端）。

因此，如果實用程式類別名為InternalLogger，則日誌將類似於：

2024-10-11T18:10:57,345 [finagle/netty4-6] (InternalLogger.java:34) INFO ...  

此處，報告的來源檔案和行號指向日誌記錄實用程式本身內的位置，而不是在應用程式程式碼中實際進行日誌呼叫的位置。此行為降低了日誌在快速偵錯和找出問題方面的有效性。

解決方案

首先，我想到在報告行號之前手動遍歷堆疊追蹤並過濾掉一些元素。這種方法的成本非常高，而且我不想減慢我們的日誌記錄過程。

幸運的是，我在這個StackOverflow 答案中發現SLF4J 提供了一個名為LocationAwareLogger 的接口，Log4J2 支援該接口，因此，我們可以透過簡單地傳遞日誌實用程式類別的FQCN（完全限定類別名稱）來過濾實用程式類別。

我原來的實用程式類別看起來像這樣：

public class InternalLogger {

  private static final Logger LOG = LoggerFactory.getLogger(InternalLogger.class);

  public void log(EventLog eventLog) {
    //... get message and logLevel from eventLog
    switch (logLevel) {
      case DEBUG:
        LOG.debug(message);
        break;
      case WARN:
        LOG.warn(message);

對於此解決方案，我聲明了 Logger 類別 FQCN 並添加了一個私人輔助函數來使用 LocationAwareLogger 進行日誌記錄：

private static final String LOGGER_UTIL_FQCN = InternalLogger.class.getName();

  private void locationAwareLog(int level, String message) {
    ((LocationAwareLogger) LOG).log(null, LOGGER_UTIL_FQCN, level, message, null, null);
  }

並更改了我的舊程式碼以在支援的情況下呼叫它：

switch (logLevel) {
  case DEBUG:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.DEBUG_INT, message);
    } else {
      LOG.debug(message);
    }
    break;
  case WARN:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.WARN_INT, message);
    } else {
      LOG.warn(message);
    }
//...

不幸的是，SLF4J 並沒有提供一種方法來提供等級作為參數（即 LOG.log(level, message)）。如果是這樣，程式碼就會稍微簡潔一些。

實施此變更後，日誌現在可以準確地報告呼叫者的線路號碼，顯著提高可追溯性：

2024-10-11T18:45:26,692 [finagle/netty4-6] (ActualLogic.java:1059) INFO ...

請注意差異：InternalLogger.java:34 與 ActualLogic.java:1059，後者指示應用程式程式碼中日誌來源的更精確位置。

結論

透過合併 SLF4J 的 LocationAwareLogger，我將我們的日誌系統從混亂的根源轉變為精確的診斷工具。此變更可以準確地報告呼叫者的線路號碼，而不是記錄實用程式的線路號碼，從而大大增強了我們快速且準確地診斷問題的能力。

這項改進不僅簡化了調試，還減少了解決軟體問題時的回應時間。

面臨類似挑戰的開發人員應該考慮這種方法來提高其日誌系統的有效性。借助更清晰、更準確的日誌，他們可以將曾經模糊的數據轉化為可操作的見解，從而提高營運效率和軟體可靠性。優化的日誌記錄對於應對當今快節奏的開發環境的挑戰並確保高品質的軟體成果至關重要。