TRACEレベルが存在する理由と、DEBUGではなくいつ使用する必要があるのですか？

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

• デバッグ
• トレース

説明が明確であるため、DEBUGの機能を理解しています。

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

しかし、TRACEレベルは、そのユースケースについてあまり明確ではありません。

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

（ソース：log4J JavaDoc）

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

これは、建築家として、私の頭の中にたくさんの旗や質問を投げかけます。若い開発者が私のアーキテクチャにTRACEを追加するように頼んだら、私は彼に質問を投げかけました：

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

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

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

一連のステップを実行するアルゴリズムがある場合、トレースレベルは、それらの各ステップに関する情報を最高レベルで出力します。すべてのステップのリテラル入力および出力のようなもの。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

個人的には、トレースはすべてをログに記録することを期待しています（たとえば、「時間Yに引数A、B、Cを使用して関数MyFuncを入力した」など）。これの欠点は、これが非常にうるさいだけでなく、ディスクスペースの問題を引き起こす傾向があることです。通常の操作では、このようなログは無効になると予想されます。利点は、これにより、デバッガーの接続があまり実用的でない場合にプログラムをステップ実行するときに得られるものと同様のレベルの情報が得られることです。

一般に、トレースは通常、他のアプローチよりも労力がかかることがわかります。

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

そうは言っても、ここでそれらがどのように使用されているかを見てみましょう。

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

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

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

ログレベルを分離する利点は、ログに記録される量を制御することです。複雑なアプリケーションの場合、トレースロギングは膨大な量のデータを記録する可能性があり、そのほとんどはほとんど役に立ちません。バグの原因を突き止めようとしない限り、重要な情報（いくつかのスタートアップ情報、そしてエラーのみ）をログに記録するのが最善です。さらに、これは一般に、デバッガーや他の開発ツールが存在しない生産環境でのみ有用です。

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

テラスティンの優れた答えは、私の短い経験則に要約できると思います。

• DEBUG ロギングは本番環境で使用できる必要があります（ただし、通常どおりオフのままになる傾向があります）
• TRACE ロギングは、本番環境での使用（特定の/短いセッション以外）を実行できないようにすることができます

これが私の経験則です

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を解決します。プロダクションマシンにどのような影響があるかはまったく関係ありませんが、コードの開発中にその情報が必要になります。あなたは「この情報を常に本番環境に記録するのは良い考えだと約束しません」と言っています。

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

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

メソッドからのENTRY / EXITログ。これらのログは、プログラムのフローをトレースするのに役立ち、次の場合に非常に役立つ傾向があります。

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

2. 一部の不正な機能は、例外を吸収することでサイレントに失敗します

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