Java ログ ユーティリティ クラスは、それ自体をログのソースとして報告していますか?それを修正する方法を学びましょう！

現代のソフトウェア開発のペースの速い環境では、効率的なデバッグとシステム監視のために効果的なロギングが重要です。ただし、ログ出力の行番号が一貫していない、または不正確であると、トラブルシューティングに時間がかかる可能性があります。最近、内部ログ ユーティリティがそれ自体をログのソースとして報告していることを確認しました。ログの精度を高めるには、この問題に対処する必要がありました。

問題

カスタム ユーティリティ クラスを使用してログを処理する場合、ユーティリティ クラスは最終的に実際のログ フレームワークを呼び出すものであるため、ログのソースとして自身を報告し始めます (私の場合、それは SLF4J でした) 、バックエンドとして Log4J2 を使用)。

したがって、ユーティリティ クラスが InternalLogger と呼ばれる場合、ログは次のようになります:

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

ここで、報告されたソース ファイルと行番号は、アプリケーション コード内で実際にログ呼び出しが行われた場所ではなく、ログ ユーティリティ自体内の場所を指します。この動作により、デバッグや問題の迅速な特定におけるログの有効性が低下します。

解決策

最初に、行番号を報告する前に手動でスタック トレースをたどっていくつかの要素を除外することを考えました。このアプローチは非常にコストがかかるため、ロギングプロセスの速度を低下させたくありませんでした。

幸いなことに、この StackOverflow の回答で、SLF4J が Log4J2 がサポートする LocationAwareLogger というインターフェイスを提供していることがわかりました。そのため、ログ ユーティリティ クラスの 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 を組み込むことで、ログ システムを混乱の原因から正確な診断ツールに変えました。この変更により、ログ ユーティリティの代わりに発信者の回線番号を正確にレポートできるようになり、問題を迅速かつ正確に診断する能力が大幅に強化されました。

この改善により、デバッグが合理化されるだけでなく、ソフトウェアの問題に対処する際の応答時間も短縮されます。

同様の課題に直面している開発者は、ロギング システムの有効性を高めるためにこのアプローチを検討する必要があります。より明確で正確なログを使用すると、これまで曖昧だったデータを実用的な洞察に変えることができ、運用効率とソフトウェアの信頼性の両方が向上します。最適化されたロギングは、今日のペースの速い開発環境の課題に対処し、高品質なソフトウェアの成果を保証するために非常に重要です。

以上がJava ログ ユーティリティ クラスは、それ自体をログのソースとして報告していますか?それを修正する方法を学びましょう！の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。