ログレベル - ログバック - ログレベルを割り当てる経験則
現在のプロジェクトで logback を使用しています。
それは6つのレベルのログ記録を提供します：TRACE DEBUG INFO WARN ERROR OFF
一般的なアクティビティのログレベルを判断するための経験則を探しています。たとえば、スレッドがロックされている場合は、ログメッセージをデバッグレベルまたは情報レベルに設定する必要があります。または、ソケットが使用されている場合は、その特定のIDをデバッグレベルまたはトレースレベルで記録する必要があります。
各ログ記録レベルについて、より多くの例を挙げて回答をいただければ幸いです。
私は主に大規模で高可用性のタイプのシステムを構築しているので、私の答えはプロダクションサポートの観点から見た方が偏っています。そうは言っても、我々はおおよそ次のように割り当てる：
エラー：システムは窮地に陥っています、顧客はおそらく影響を受けています（または近いうちにそうなるでしょう）、そしてその修正にはおそらく人間の介入が必要です。 「2AMルール」がここに適用されます。通話中の場合、この状態が発生した場合に午前2時に起床しますか？そうであれば、それを「エラー」としてログに記録します。
warn：予期しない技術的または業務上の出来事が発生した場合、顧客が影響を受ける可能性がありますが、おそらく即時の人的介入は必要ありません。電話ではすぐに電話がかけられることはありませんが、サポート担当者は、影響が何であるかを理解するためにできるだけ早くこれらの問題を確認したいと思うでしょう。基本的に追跡する必要があるが即時の介入を必要としない可能性があるすべての問題。
info：問題を法医学的に分析する必要がある場合に備えて、大量に見たいもの。システムライフサイクルイベント（システムの開始、停止）はここにあります。 「セッション」ライフサイクルイベント（ログイン、ログアウトなど）はここにあります。重大な境界イベント（データベース呼び出し、リモートAPI呼び出しなど）も考慮する必要があります。典型的なビジネス上の例外はここに行くことができます（例えば、悪い信用証明のためにログインが失敗した）。プロダクションで大量に見る必要があると思うその他のイベントはすべてここにあります。
debug：「情報」をカットしないものすべてについて...システム内のフローを追跡して分離するのに役立つメッセージ特に開発およびQA段階での問題私たちは、ほとんどの重要ではないメソッドの入り口/出口に「デバッグ」レベルのログを使用し、メソッド内の興味深いイベントや決定点をマークします。
trace：これはあまり使用しませんが、非常に詳細で大量の可能性があるログで、通常は有効にしたくない場合があります。通常の発達。例としては、完全なオブジェクト階層のダンプ、ラージループの繰り返しごとの状態の記録などがあります。
適切なログレベルを選択すること以上に重要なのは、ログが意味のあるものであり、必要なコンテキストを持っていることを確認することです。たとえば、必要に応じて単一のスレッドを追跡できるように、ほとんどの場合はログにスレッドIDを含めます。ビジネス情報（ユーザーIDなど）をスレッドに関連付けるメカニズムを採用して、ログに記録することもできます。ログメッセージには、メッセージを確実に実行可能にするのに十分な情報を含める必要があります。 "FileNotFound exception catch"のようなログはあまり役に立ちません。より良いメッセージは、「設定ファイルを開く際にFileNotFound例外が発生しました：/usr/local/app/somefile.txt.userId = 12344」です。
そこにはたくさんの良いロギングガイドもあります...例えば、これは JCL（Jakarta Commons Logging） からの編集された断片です。
- error - その他の実行時エラーまたは予期しない状態これらがステータスコンソールにすぐに表示されることを期待してください。
- warn - 廃止予定のAPIの使用、APIの不適切な使用、「ほぼ」エラー、その他の実行時の状況（望ましくない、または予期しない、ただし必ずしも「間違っている」とは限らない）。これらがステータスコンソールにすぐに表示されることを期待してください。
- info - 興味深いランタイムイベント（起動/シャットダウン）これらはコンソール上ですぐに見えるようになるので、控えめにして最小限に留めてください。
- debug - システムを通過するフローに関する詳細情報これらはログのみに書き込まれることを期待してください。
- トレース - より詳細な情報。これらはログのみに書き込まれることを期待してください。
私のアプローチは、運用の観点よりも開発から来たものだと思います。
- エラーは、あるタスクの実行が完了できなかったことを意味します。 Eメールを送ることができず、ページをレンダリングすることもできず、データをデータベースに保管することもできませんでした。決定的に何かが間違っています。
- 警告は、予期しないことが起こったことを意味しますが、実行は、おそらく低下モードで継続できます。設定ファイルがありませんでしたが、デフォルトが使用され、価格は負の値として計算されたため、ゼロに固定されていました。何かは正しくありませんが、まだ正しく行われていません。すぐにエラーが発生しました。
- Infoは普通だが重要なことが起こったことを意味します。システムが起動し、システムが停止し、日々の在庫更新ジョブが実行された、などなどです。
- Debugは、普通で意味のないことが起こったことを意味します。新しいユーザーがそのサイトにやってきて、ページがレンダリングされ、注文がなされ、価格が更新されたそれが多すぎるので、これはinfoから除外されたものです。
- Traceは私が実際に使ったことがないものです。
これは、ある特定のレベルでのrequest（コードからの）ロギングが実際にはロギングされているかどうか有効ロギングレベルが与えられているかどうかを理解するのにも有効です。で構成されています。何を決定します有効他のAnswersから展開を設定したいレベルですか？そして、これを参照して特定のロギングが実際にログに記録されるかどうかを確認してくださいrequestそれで….
例：
- 「WARNでログを記録するロギングコード行は、実際にはERRORで設定された私のデプロイメントにログオンしますか？」表にはあります、NO。
- 「WARNでログを記録するロギングコード行は、実際にはDEBUGで設定された私のデプロイメントにログオンしますか？」その表はそうです、はい。
from logback documentation：
よりグラフィックな方法で、これは選択規則がどのように働くかです。次の表では、垂直方向のヘッダーはpで示されているロギング要求のレベルを示し、水平方向のヘッダーはqで示されているロガーの有効レベルを示しています。行（レベル要求）と列（有効レベル）の共通部分は、基本選択規則から生じるブール値です。
そのため、ロギングを要求するコード行は、実際にはその展開の有効ロギングレベルがそのコード行の要求重大度レベル以下である場合にのみログに記録されます。
私はこれに答えるのは、組織がお互いに依存している可能性がある多くのコンポーネントを実行している可能性があるコンポーネントベースのアーキテクチャから来ています。障害が伝播している間、ロギングレベルはどのコンポーネントが影響を受けているのか、そしてどのコンポーネントが根本的な原因であるのかを識別するのに役立ちます。
ERROR - このコンポーネントは失敗しており、その原因は内部的なものであると考えられます（内部の未処理の例外、カプセル化された依存関係の失敗...たとえばデータベース、RESTの例依存関係から4xxエラーを受け取りました。私（このコンポーネントのメンテナ）をベッドから外してください。
WARN - このコンポーネントは依存コンポーネントによって引き起こされると考えられている失敗をしました（RESTの例は依存関係からの5xxステータスでしょう）。そのコンポーネントのメンテナをベッドから外します。
INFO - 私たちが演算子に渡したいその他のこと。あなたが幸せなパスを記録することに決めたならば、私は重要な操作ごとに1つのログメッセージに制限することをお勧めします（例えば入って来るhttpリクエストごとに）。
すべてのログメッセージについて、有用なコンテキストをログに記録するようにしてください（そして、「エラーコード」が大量にあるのではなく、メッセージを人間が読めるようにする/便利にすることを優先してください）
- DEBUG（およびそれ以下） - まったく使用すべきではありません（そして確かに本番では使用しないでください）。開発においては、log文でコードを汚染するのではなく、TDDとデバッグ（必要な場合）の組み合わせを使用することをお勧めします。本番環境では、上記のINFOロギングを他の測定基準と組み合わせれば十分です。
上記のロギングレベルを視覚化するための良い方法は、各コンポーネントの一連の監視画面を想像することです。すべて正常に動作している場合、それらは緑色です。コンポーネントが警告をログに記録すると、オレンジ色（オレンジ色）になり、エラーが記録されると赤色になります。
インシデントが発生した場合は、1つの（根本原因）コンポーネントが赤くなり、影響を受けるすべてのコンポーネントがオレンジ色/オレンジ色になるはずです。
他の答えと違いはありませんが、私のフレームワークはほぼ同じレベルです。
- エラー：データベース接続のタイムアウトなど、アプリケーション上の重大な論理エラー。近い将来バグ修正を要求するもの
- 警告：重大な問題ではありませんが、注意を払うべきものです。リクエストされたページが見つかりませんでした
- Info：関数/メソッドの1行目で、挿入された問い合わせのように、呼び出された手続きや正常に終了した手順を示す
- log：if文の結果のような論理情報
- debug：恒久的に監視することに関連する変数の内容