ログ レベル WARN、ERROR、および FATAL は非常に明確です。しかし、いつ何かが DEBUG で、いつ INFO ですか?
INFO レベルで面倒なほど冗長なプロジェクトをいくつか見てきましたが、DEBUG レベルを優先しすぎるコードも見てきました。どちらの場合も、有用な情報はノイズの中に隠されています。
ログレベルを決定する基準は何ですか?
ログ レベル WARN、ERROR、および FATAL は非常に明確です。しかし、いつ何かが DEBUG で、いつ INFO ですか?
INFO レベルで面倒なほど冗長なプロジェクトをいくつか見てきましたが、DEBUG レベルを優先しすぎるコードも見てきました。どちらの場合も、有用な情報はノイズの中に隠されています。
ログレベルを決定する基準は何ですか?
厳格なルールはないと思います。log4j タイプのレベルを使用すると、私の「経験則」は次のようになります。
決まったものではありませんが、私がどのように考えているかについての大まかな考えです。
非公式に、私はこの種のヒエラルキーを使用しています。
通常、INFO がログに記録された状態でリリースしますが、ログ ファイルが実際にレビューされていることがわかっている場合 (およびサイズが問題ではない場合) にのみ、それ以外の場合は WARN です。
各レベルを誰が使用する必要があるかを考えてください。私のコードでは、DEBUGを開発者の出力用に予約しておきます。たとえば、開発者だけに役立つ出力です。 VERBOSEは、多くの情報が必要な場合に通常のユーザーに使用されます。 INFO通常、主要なイベントを表示するために使用します (たとえば、Web ページの送信、重要なもののチェックなど)。
そしてFAILとWARNは一目瞭然です。
私のチームの慣習はdebug
、メッセージで何かが計算された場合に使用するのに対してinfo
、プレーンテキストに使用されることです。事実上、info
何が起こっているかdebug
を示し、起こっていることの価値を示します。
私は INFO をユーザーに向けて、警告でさえないメッセージを表示する傾向があります。DEBUG は開発者が使用する傾向があり、メッセージを出力してコード全体の流れを追跡するのに役立ちます (変数の値も含む)。
また、別のレベルの DEBUG (DEBUG2?) も気に入っています。これは、すべてのバッファーの 16 進ダンプなどのデバッグ情報の絶対バケットロードを提供します。
DEBUG2レベルは必要ありません。それが「TRACE」の目的です。TRACEは、表示する可能性のあるすべての情報を出力する、絶対的な最低レベルのロギングを目的としています。
大量の情報を回避するために、プロジェクト全体でトレースレベルのログを有効にすることは一般的に推奨されていません。代わりに、「DEBUG」を使用してバグとその発生場所に関する一般的な情報(名前の由来)を確認し、それでも理解できない場合は、そのコンポーネントに対してのみTRACEを有効にします。