web-dev-qa-db-ja.com

TRACEレベルが存在するのはなぜですか、またDEBUGではなくいつそれを使用する必要がありますか？

Log4J、Slf4J、およびJavaの他のいくつかのロギングフレームワークでは、ロギング用に2つの「開発者」レベルがあります。

  • デバッグ
  • 痕跡

説明がはっきりしているので、私はデバッグが何をするのか理解しています：

DEBUGレベルは、アプリケーションのデバッグに最も役立つ詳細な情報イベントを指定します。

ただし、TRACEレベルはそのユースケースについてあまり具体的ではありません。

TRACEレベルは、DEBUGよりも細かい情報イベントを指定します

（ソース： log4J JavaDoc ）

これは、TRACEをいつどのように使用するかを教えてくれません。興味深いことに、これは syslog標準 で定義されている重大度レベルではありません。 TRACEとDEBUGの違いをググリングすると、「DEBUGを使用する、そしてTRACEもある」という結果が返されるようです。 TRACEレベルの特定の使用例が見つかりませんでした。私が見つけることができた最高のものは この古いwikiページ レベルの存在のメリットについての議論でした。

建築家として、これは私の頭の中で多くのフラグと質問を提起します。若い開発者が私のアーキテクチャにTRACEを追加するように依頼した場合、私は彼に次のような質問を投げかけます。

  • DEBUGではなくTRACEで記録する必要がある情報の例は何ですか？
  • その情報を記録することで、どのような特定の問題を解決できますか？
  • これらの例で、clearlyがDEBUGレベルではなくTRACEレベルでのロギングを区別するログ情報のプロパティは何ですか？
  • なぜその情報がログインフラストラクチャを通過する必要があるのですか？
    • System.out.printlnを使用するだけでなく、ログジャーナルにその情報を保持する利点は何ですか？
    • デバッガよりもログを使用する方が良いのはなぜですか？
  • TRACEレベルでのロギングの標準的な例は何ですか？
    • この例のDEBUGではなく、TRACEレベルでログを記録することで得られた具体的なメリットは何ですか？
    • なぜそれらの利益が重要なのですか？
    • 逆に：DEBUGの代わりにTRACEにログを記録することで、どのような問題を回避できましたか？
    • 他にどのようにこれらの問題を解決できますか？ TRACEレベルでのロギングが他のソリューションよりも優れているのはなぜですか？
  • TRACEレベルのログステートメントを製品コードに残す必要がありますか？どうして？

しかし、それがほとんどの主要なフレームワークに存在することを考えると、何かに役立つと思いますか？それで... TRACEは何のためにあり、何がそれをデバッグと区別するのですか？

javalogging
96
Laurent Bourgault-Roy

DEBUGではなくTRACEで記録する必要がある情報の例は何ですか？

一連のステップを実行するアルゴリズムがある場合、トレースレベルはそれらの各ステップに関する情報を最も細かいレベルで出力します。各ステップの文字通りの入力と出力のようなもの。

一般に、トレースにはすべてのデバッグが含まれます（デバッグにすべての警告とエラーが含まれるのと同じように）。

その情報をログに記録することによって、どのような特定の問題を解決できますか？

wayを出力するものをデバッグする必要がある場合、特定のビルドを対象とする場合、特定のビルドの外部にログを記録するにはエラーやその他のロギング情報は気にしないでください（トレース情報の量が原因で不明瞭になるため）。一部のロガーでは、特定のモジュールをトレースレベルのみに上げます。

これらの例では、DEBUGレベルではなくTRACEレベルでのロギングを明確に区別するログ情報のプロパティは何ですか？

一般に、トレースレベルのロギングは、アプリケーションのパフォーマンスを大幅に低下させたり、ディスク/帯域幅の制約のために持続不可能である大量のログデータを作成したりするため、継続的にオンにすることはできません。

通常、デバッグレベルのロギングは、アプリを使用できなくすることなく、より長い期間オンにすることができます。

なぜその情報はログインフラストラクチャを経由する必要があるのですか？

必要はありません。一部のフレームワークには、個別のトレースロガーがあります。

トレースロガーと通常のロガーは、ディスク/ネットワークへの書き込み、エラー処理、ログのローテーションなどに関して同様のニーズがあるため、通常はログに記録されます。

デバッガよりもログを使用する方が良いのはなぜですか？

デバッガーが問題のあるマシンに接続できない可能性があるためです。ブレークポイントをどこに設定するか、またはコードをステップ実行するための十分な知識がないかもしれません。デバッガーでエラーを確実に再現できない可能性があるため、ログを使用して「発生した場合」にそれをキャッチします。

しかし、それらは単なる名前です。他のレーベルと同様に、それらは単に人が物を付ける名前であり、通常は人によって異なることを意味します。また、ラベル自体は、ラベルが参照する肉の部分ほど重要ではありません。

65
Telastyn

Slf4jがトレース（ http://slf4j.org/faq.html#trace ）の使用を特に推奨しないことに特に注意してください：

つまり、代替案が存在するため、または多くの場合レベルTRACEのログリクエストが無駄であるため、TRACEレベルの使用はまだ推奨されていませんが、人々が求め続けていることを考えると、人気の需要に屈することにしました。

個人的には、トレースがログに記録することが期待されますeverything（たとえば、「入力された関数MyFuncに引数A、B、Cを時間Yで」のようなものでも）。これの欠点は、これが信じられないほどうるさいだけでなく、ディスク容量の問題を引き起こす傾向があることです。通常の操作中は、このようなロギングが無効になると思います。良い点は、デバッガーをアタッチすることがあまり実用的でない場合に、プログラムをステップ実行したときに得られる情報と同様のレベルの情報を提供することです。

一般に、通常、トレースは他のアプローチよりも手間がかかります。

16
Brian

一般に、デバッグレベルは完全に任意であり、言語、ライブラリ、企業によって異なります。

そうは言っても、ここで私はそれらが使用されているのを見てきました：

TRACE：ロジックレベルのプログラムフローを表示するために使用されます。関数に入ったか？ 「if」ステートメントはメインまたは「else」ブランチを選択しましたか？それはトレースの候補です。つまり、トレースログは通常、「現在地」を指定するために使用されます。これは、エラーやその他の情報をログに記録する可能性がある他のロギングステートメントのコンテキストで役立ちます。トレースログは、異なるレベルでログに記録されたエラーまたは他のイベントのコード内の場所を特定するのに役立ちます。

デバッグ：変数の状態、特定のエラーコードなどをダンプするために使用されます。例：Webサービスがエラーコード809214を返すことがあります。エラーが発生した後、開発者がユーザーのシステムからログを受け取り、「なぜ障害が発生したのか？」これは、デバッグレベルでログを記録するのに適しています。別の例としては、バグが本番環境で発生し続けるが再現が難しい場合、トラブルシューティングに役立つエラーが発生したときにプログラムの状態を開発者に知らせるために、問題のあるモジュールの特定の変数またはイベントをデバッグログに記録します。

通常、特定のレベル（またはそれ以上）でログを記録するようにアプリケーションを構成します。たとえば、トレースは多くの場合最低レベルです。そのレベルでのロギングはすべてをログに記録します。デバッグレベルはトレースを省略しますが、高レベル（警告やエラーなど）を含みます。

ログレベルを分離する利点は、ログに記録される量を制御できることです。複雑なアプリケーションの場合、トレースロギングは膨大な量のデータをログに記録する可能性があり、そのほとんどはほとんどの場合無用です。重要な情報のみをログに記録することをお勧めします（たぶんいくつかの起動情報、その後はエラーのみ）nlessバグの原因を特定しようとしています。さらに、これは通常、デバッガーや他の開発ツールが存在しない運用環境でのみ役立ちます。

これには実際の制限はなく、特定の方法でログを記録する必要があるというルールはありません。一部のライブラリまたはアプリケーションが従う可能性のある、または従わない可能性のある広範な規則のみ。

14
user22815

これが私の経験則です

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

この背後にある仮定は、運用チームが

  • 常に本番環境をログレベルの情報に設定します
  • 本番環境でログレベルのデバッグが設定されている可能性があります
  • 本番環境でログレベルのトレースを設定しないでください

その仮定を武器に、開発者がログレベルを使用する方法を次に示します...

目的＃1）本番のパフォーマンスをあまり低下させないこと

debugは＃1を解決します。開発者としてあなたは、マシンの速度を落とすノイズが多すぎないように、本番環境で必要となる可能性のある情報のバランスを取るために最善を尽くしています。 「（もし望むなら）これを常に本番環境に記録するのは良い考えです」とあなたは言っています。

目的＃2）開発中に詳細な情報を持つ

traceは問題＃2を解決します。プロダクションマシンにどのような影響があるかはまったく問題ではありませんが、コードを開発するときに、その情報が必要です。あなたは「私は常にこの情報を本番環境に記録することは良い考えだとは約束しません」と言っています。

確かに（他の人が言ったように）、これらは恣意的です。したがって、開発チーム（およびops /監視チーム-ロギングのユーザーでもあるため）が何かに同意していることを確認してください。

10
Alexander Bird

私は Telastynの優れた答え は私の短い経験則に要約できると思います：

  • DEBUGロギングは本番環境で使用できる必要があります（ただし、通常はオフのままになる傾向があります）
  • TRACEロギングは、（特定の/短いセッション以外の）本番環境での使用が実行不可能になるように許可されています
9
Martin Ba

TRACEレベルでのロギングの標準的な例は何でしょうか？

メソッドからのENTRY/EXITログ。これらのログはtraceプログラムのフローに役立ち、次の場合に非常に役立ちます。

  1. プログラムが突然クラッシュする-ログの最後の行を見れば、クラッシュした関数が正確にわかります。

  2. 例外を吸収することにより、いくつかの不正な機能が静かに失敗

コードベースのすべてのメソッドでENTRY/EXITログを有効にすると、膨大な量の余分なログが生成され、always onであっても不合理になるため、DEBUGを使用するのではなく、個別のTRACEレベルが保証されます。 DEBUGコンテキストで。

3
dotbugfix