これは純粋に主観的な質問かもしれませんが (これを標準化しようとした組織がない場合)、私のチームはあなたが思っている以上にこれに苦労しています.
私たちはロギング インターフェイスとして Apache Commons Logging を使用していますが、多くの場合、優先度の使用は開発チーム全体で一貫していません。たとえば、一部の開発者は、フローがエラーを処理できる場合でも、キャッチされた例外を致命的 (log.fatal(message)) にログ記録しますが、他の開発者は、なんらかの理由でプログラムの実行が必然的に停止した場合にのみ致命的にログを記録します。
他のチームがそれぞれの優先順位をどのように定義しているか知りたいです。このためのベストプラクティスを明示的に定義しようとしている会社で働いている人はいますか? ジャカルタはこれに加担しましたか？
私の目標は、優先度ごとの簡単な推奨事項をチーム全体に送信して、一貫した方法で扱いにくいアプリケーション ログをより効果的に処理できるようにすることです。
これが私たちが使用するものです（そして、他の多くのものも同様だと思います）：
場合によっては、通常は発生したくないことが発生したときに通知を受け取るために、メッセージを ERROR としてログに記録することから始めます。後で、そのエラーの原因を取り除くことができないと判断した場合は、それを処理し、ログ レベルを WARN に変更します。
テスト システムと本番システムは、FATAL と ERROR の電子メールを送信するように設定されていることに注意してください。したがって、それらのログ ファイルを手動で確認する必要はなく、1 つの電子メールの受信トレイを確認するだけで済みます。
それが役立つことを願っています。
編集: Apache Commons Logging のベスト プラクティスは既にご覧になりましたか?
私はいつもこれをガイドラインとして使用してきました。Commons LoggingよりもLog4jを使用していますが、これでも役立つ場合があります。
DEBUG-純粋にデバッグレベルの情報用。INFOが最小レベルになるため、製品または出荷された製品には表示されません。タイミング、イベントの発生数などをキャプチャするのに適しています
INFO-本番/出荷時の使用の最小レベル。フォレンジック調査および成功した結果の確認に役立つ可能性のあるデータを記録します（「999アイテムをDB OKに保存」）。ここにあるすべての情報は、必要に応じて、エンドユーザー/顧客がそれを見て送信しても問題ないようなものでなければなりません（秘密や冒涜はありません！）
警告-それ自体はエラーレベルではありませんが、システムが危険な領域に入っている可能性があることを知っておくと便利です。たとえば、「注文した製品の数<0」のようなビジネスロジックは、どこかにバグがあることを示唆していますが、システムの例外ではありません。正直に言うと、あまり使用しない傾向があります。物事を見つけることは、INFOまたはERRORにより自然に適合する傾向があります。
エラー-これを例外に使用します（WARNまたはINFOに減らす正当な理由がない限り）。診断が不可能な重要な変数値とともに、完全なスタックトレースをログに記録します。悪いビジネスロジックの状況ではなく、アプリ/システムエラーにのみ使用してください
致命的-これは、文字通りアプリの起動/続行を妨げるような重大度の高いエラーにのみ使用してください
さらに、DEBUGレベルとINFOレベルの両方をアクティブにして、ログを頻繁に確認します。目立つイベントを見つけやすく、読みやすさを損なうような冗長なことをしていないことを確認してください。 。
また、タイムスタンプ、ソースクラス、重大度などの適切な列につながるパターンを使用するようにしてください。これも、読みやすさを大幅に向上させます。
私の見解
これは私の会社が推奨するものです：
TRACE-メッセージはおそらく開発サイクル中にのみ有用であり、本番環境で適切に使用するにはあまりにも頻繁に生成される可能性があります。たとえば、内部ループで中間値をログに記録する場合は、TRACEを使用します。
DEBUG-サーバーの通常の実行におけるさまざまなステップをログに記録するために使用されるメッセージ。通常、これらは運用スタッフではなく開発者を対象としています。
INFO-本番環境でログに記録されると予想されるポジティブまたはニュートラルな性質のメッセージ。運用スタッフにとって意味のあるものでなければなりません。
警告-サーバーが要求に正確かつタイムリーに応答する能力を危険にさらす可能性のある状態を示すメッセージ。
エラー-予期しない動作または状態を示すメッセージ。
FATAL-アプリケーションプロセスの継続的な実行を不可能または危険なままにする予期しない動作または状態を示すメッセージ。
本番環境のログはINFOに設定され、開発者以外の人にも読み取られることを期待しています。ログメッセージのスタイルはまったく別の会話です...
業界でサポートされている簡単な推奨事項を探している場合は、業界の簡単な実装/ドキュメントを見てみませんか？
ロギングレベルガイドlogbackとして/ log4jAPIを使用します=>これにより、業界でシンプル/文書化/サポートされます。
レベルALLのランクは可能な限り低く、すべてのロギングをオンにすることを目的としています。
レベルDEBUGは、アプリケーションのデバッグに最も役立つ詳細な情報イベントを指定します。
レベルERRORは、アプリケーションの実行を継続できる可能性のあるエラーイベントを示します。
レベルFATALは、アプリケーションを中止させる可能性のある非常に重大なエラーイベントを指定します。
レベルINFOは、大まかなレベルでアプリケーションの進行状況を強調する情報メッセージを指定します。
レベルOFFは可能な限り最高のランクであり、ロギングをオフにすることを目的としています。
レベルTRACEは、DEBUGよりもきめ細かい情報イベントを指定します
レベルWARNは、潜在的に有害な状況を示します。
私はより簡単なアプローチを使用しています：
DEBUG : 本番環境ではオフになっているため、主に開発者が特定のクエリ、タイミング、パラメーター値などを記録するために使用します。
INFO : すべてをログに記録して、結果がどのように計算されたかを説明し、バグを修正できるように、すべてを振り返って確認します。
エラー: 誰か (開発者/運用) の注意が必要なものすべて
WARN メッセージのすべてのログ ファイルをフィルター処理する人はいないため、私はWARNを使用しません。重要な場合は ERROR (だれかが気にかけなければなりません) であり、重要でない場合は INFO です (問題が発生するまで誰も関心を持ちません)。FATALも同様。
TRACEも使用しません。開発中に私が知る必要があるのは DEBUG だけです。