ログレベル-ログバック-ログレベルを割り当てるための経験則

現在のプロジェクトでlogbackを使用しています。

6つのレベルのロギングを提供します。TRACEDEBUG INFO WARN ERROR OFF

一般的なアクティビティのログレベルを決定するための経験則を探しています。たとえば、スレッドがロックされている場合、ログメッセージをデバッグレベルまたは情報レベルに設定する必要があります。または、ソケットが使用されている場合、その特定のIDをデバッグレベルまたはトレースレベルで記録する必要があります。

各ロギングレベルの例を追加して回答をいただければ幸いです。

私は主に大規模で高可用性タイプのシステムを構築しているので、私の答えは、実稼働サポートの観点から見たものに偏っています。つまり、次のように大まかに割り当てます。

• エラー：システムに問題があり、顧客はおそらく影響を受けており（まもなく影響を受ける）、修正にはおそらく人間の介入が必要です。「2AMルール」がここに適用されます-通話中の場合、この状態が発生した場合、午前2時に起こされますか？はいの場合は、「エラー」として記録します。

• 警告：予期しない技術イベントまたはビジネスイベントが発生しました。顧客に影響が及ぶ可能性がありますが、おそらく人間による即時の介入は必要ありません。オンコールの担当者がすぐに電話を受けることはありませんが、サポート担当者はこれらの問題をできるだけ早く確認して、影響を理解する必要があります。基本的に追跡する必要があるが、すぐに介入する必要がない問題。

• info：問題を科学的に分析する必要がある場合に備えて、大量に見たいもの。システムライフサイクルイベント（システムの開始、停止）はここにあります。「セッション」ライフサイクルイベント（ログイン、ログアウトなど）はここに移動します。重要な境界イベントも考慮する必要があります（データベース呼び出し、リモートAPI呼び出しなど）。典型的なビジネス例外がここに入る可能性があります（たとえば、資格情報が正しくないためにログインに失敗しました）。大量生産で確認する必要があると思われるその他のイベントがここに表示されます。

• debug：「情報」を削減しないすべてのこと...システムのフローを追跡し、問題を特定するのに役立つメッセージ（特に開発フェーズとQAフェーズの間）。私たちは、ほとんどの重要なメソッドの入り口/出口に「デバッグ」レベルのログを使用し、メソッド内の興味深いイベントと決定ポイントにマークを付けます。

• トレース：これは頻繁には使用しませんが、通常の開発中でも通常は有効にしたくない、非常に詳細で大量の可能性があるログの場合に使用します。例としては、完全なオブジェクト階層のダンプ、大規模なループの反復ごとの状態のロギングなどがあります。

適切なログレベルを選択すること以上に重要なことは、ログが意味のあるものであり、必要なコンテキストを持つことを保証することです。たとえば、ほとんどの場合、ログにスレッドIDを含めることで、必要に応じて単一のスレッドを追跡できます。また、ビジネス情報（ユーザーIDなど）をスレッドに関連付けてログに記録するメカニズムを採用することもできます。ログメッセージには、メッセージを実行可能にするために十分な情報を含める必要があります。「FileNotFound例外がキャッチされました」のようなログはあまり役に立ちません。より良いメッセージは、「構成ファイルを開こうとしているときにFileNotFound例外がキャッチされました：/usr/local/app/somefile.txt。userId = 12344」です。

多くの優れたロギングガイドもあります...たとえば、JCL（Jakarta Commons Logging）からの編集されたスニペットは次のとおりです。

• error-その他の実行時エラーまたは予期しない状態。これらがステータスコンソールにすぐに表示されることを期待してください。
• 警告-非推奨のAPIの使用、APIの不適切な使用、「ほとんど」のエラー、望ましくないまたは予期しない他の実行時の状況ですが、必ずしも「間違っている」とは限りません。これらがステータスコンソールにすぐに表示されることを期待してください。
• info-興味深いランタイムイベント（スタートアップ/シャットダウン）。これらがコンソールにすぐに表示されることを期待するので、控えめにして、最小限に留めてください。
• debug-システムを通過するフローに関する詳細情報。これらがログにのみ書き込まれることを期待してください。
• トレース-より詳細な情報。これらがログにのみ書き込まれることを期待してください。

私のアプローチは、運用の観点よりも開発から来ると思います：

• エラーは、一部のタスクの実行を完了できなかったことを意味します。電子メールを送信できなかった、ページをレンダリングできなかった、一部のデータをデータベースに保存できなかった、など。間違いなく何かが間違っています。
• 警告は、予期しない事態が発生したものの、おそらく機能低下モードで実行が継続する可能性があることを意味します。構成ファイルがありませんでしたが、デフォルトが使用され、価格は負の値として計算されたため、ゼロにクランプされました。間もなくエラーが発生します。
• 情報とは、通常の重要なことが起こったことを意味します。システムが起動した、システムが停止した、毎日の在庫更新ジョブが実行された、など。これらの継続的な急流があってはなりません。
• デバッグとは、通常の重要でない何かが起こったことを意味します。新しいユーザーがサイトにアクセスし、ページがレンダリングされ、注文が行われ、価格が更新されました。情報が多すぎるため、これは情報から除外されたものです。
• トレースは、私が実際に使用したことがないものです。

これは、特定のレベルでの（コードからの）ロギングリクエストにより、デプロイメントが構成されている有効なロギングレベルを前提として実際にログが記録されるかどうかを理解するのに役立ちます。ここで他の回答から展開を構成する有効なレベルを決定し、これを参照して、コードからの特定のログリクエストが実際にログに記録されるかどうかを確認してください...

例：

• 「WARNでログを記録するログコード行は、実際にERRORで構成されたデプロイメントに記録されますか？」テーブルは言う、NO。
• 「WARNでログを記録するログコード行は、実際にDEBUGで構成されたデプロイメントに記録されますか？」テーブルには「はい」と書かれています。

ログバックのドキュメントから：

よりグラフィックな方法で、選択ルールがどのように機能するかを示します。次の表では、垂直ヘッダーはpで指定されたロギングリクエストのレベルを示し、水平ヘッダーはqで指定されたロガーの有効レベルを示します。行（レベルリクエスト）と列（有効レベル）の共通部分は、基本的な選択ルールから得られるブール値です。

したがって、ロギングを要求するコード行は、そのデプロイメントの有効なロギングレベルがそのコード行の要求された重大度レベル以下である場合にのみ実際にログが記録されます。

これは、組織が相互に依存している可能性のある多くのコンポーネントを実行している可能性があるコンポーネントベースのアーキテクチャから来るものです。障害の伝播中、ログレベルは、影響を受けるコンポーネントと根本原因の両方を特定するのに役立ちます。

• エラー -このコンポーネントに障害があり、原因は内部にあると考えられています（内部の未処理の例外、カプセル化された依存関係の失敗...たとえば、データベース、RESTの例では、依存関係から4xxエラーを受け取ったでしょう）。私（このコンポーネントのメンテナ）をベッドから出してください。

• 警告 -このコンポーネントには、依存コンポーネントによって引き起こされると考えられる障害がありました（RESTの例は、依存関係からの5xxステータスです）。THATコンポーネントのメンテナをベッドから解放します。

• INFO-オペレーターに連絡したいその他すべて。ハッピーパスをログに記録することにした場合は、重要な操作（たとえば、着信HTTP要求）ごとに1つのログメッセージに制限することをお勧めします。

すべてのログメッセージについて、必ず有用なコンテキストをログに記録してください（そして、「エラーコード」の連なりではなく、メッセージを人間が読める/有用なものにすることを優先します）

• DEBUG（およびそれ以下）-まったく使用しないでください（実際には使用しないでください）。開発では、コードをログステートメントで汚染するのではなく、TDDとデバッグ（必要な場合）を組み合わせて使用​​することをお勧めします。本番環境では、上記のINFOロギングと他のメトリックを組み合わせれば十分です。

上記のログレベルを視覚化する良い方法は、各コンポーネントの一連の監視画面を想像することです。すべて正常に動作している場合は緑色で、コンポーネントが警告をログに記録している場合はオレンジ（オレンジ色）になり、エラーを記録している場合は赤色になります。

インシデントが発生した場合は、1つの（根本原因）コンポーネントが赤になり、影響を受けるすべてのコンポーネントがオレンジ/オレンジになります。

他の回答と同じですが、私のフレームワークはほぼ同じレベルです。

1. エラー：データベース接続タイムアウトなど、アプリケーションでの重大な論理エラー。近い将来バグ修正が必要なもの
2. 警告：重大な問題ではありませんが、注意すべき点があります。リクエストされたページが見つからないように
3. 情報：関数/メソッドの最初の行で使用され、呼び出されたプロシージャまたは正常に実行されたステップを示します。
4. ログ：ifステートメントの結果などの論理情報
5. debug：永続的に監視する必要がある変数の内容