Java ログユーティリティクラスは、それ自体をログのソースとして報告していますか?それを修正する方法を学びましょう！-＆＃＆チュートリアル-php.cn

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

Barbara Streisand

リリース： 2024-10-13 06:13:30

オリジナル

508 人が閲覧しました

Is your Java log utility class reporting itself as the source of your logs? Learn how to fix it!

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

問題

カスタムユーティリティクラスを使用してログを処理する場合、ユーティリティクラスは最終的に実際のログフレームワークを呼び出すものであるため、ログのソースとして自身を報告し始めます (私の場合、それは 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 サイトの他の関連記事を参照してください。