回答:
私は通常、次の規約に同意します。
Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).。Logger.Debugは、開発者が本番環境での非常に厄介な問題を追跡するためのものです。例If you want to print the value of a variable at any given point inside a for loop against a condition
深夜にシステム管理者を寝かしつけるメッセージを送信しますか？
FATALシステム管理者が目を覚まし、これに対して十分な支払いが行われていないと判断して、スリープ状態に戻るときです。
ログファイルを表示するという観点から重大度を考えると、より役立ちます。
致命的/クリティカル：アプリケーションまたはシステム全体の障害で、すぐに調査する必要があります。はい、SysAdminを起動します。私たちはSysAdminsアラートと十分に休息することを好みますので、この重大度は非常にまれにしか使用されません。それが毎日起こり、それがBFDではない場合、それは意味を失っています。通常、致命的なエラーはプロセスの存続期間中に一度だけ発生するため、ログファイルがプロセスに関連付けられている場合、これは通常、ログの最後のメッセージです。
エラー：調査が必要な問題です。SysAdminは自動的に通知されますが、ベッドからドラッグする必要はありません。ログをフィルタリングしてエラーを確認することにより、エラーの頻度の概要が得られ、追加のエラーのカスケードを引き起こした可能性のある初期の障害をすばやく特定できます。エラー率をアプリケーションの使用状況と比較して追跡すると、全体的な品質を評価するために使用できるMTBFなどの有用な品質メトリックが得られます。たとえば、この測定基準は、リリース前に別のベータテストサイクルが必要かどうかについての判断に役立つ場合があります。
警告：これは問題である可能性があります。たとえば、ネットワークやデータベースの接続が一時的に失われるなどの予期される一時的な環境条件は、エラーではなく警告としてログに記録する必要があります。警告とエラーのみを表示するようにフィルタリングされたログを表示すると、後続のエラーの根本的な原因に関する初期のヒントをすばやく知ることができます。警告は、意味がなくならないように控えめに使用する必要があります。たとえば、ネットワークアクセスの喪失は、サーバーアプリケーションでは警告またはエラーになるはずですが、ときどき切断されたラップトップユーザー向けに設計されたデスクトップアプリの単なる情報である可能性があります。
情報：これは、正常な初期化、サービスの開始と停止、または重要なトランザクションの正常な完了などの通常の条件下でログに記録する必要がある重要な情報です。情報以上を示すログを表示すると、プロセスでの主要な状態変化の概要がすぐにわかり、発生する警告またはエラーを理解するための最上位のコンテキストが提供されます。Infoメッセージが多すぎないようにしてください。通常、Traceと比較して5％未満の情報メッセージがあります。
トレース：トレースは、最も一般的に使用される重大度であり、エラーと警告に至るまでの手順を理解するためのコンテキストを提供する必要があります。Traceメッセージの密度を適切にすると、ソフトウェアの保守性が大幅に向上しますが、個々のTraceステートメントの値はプログラムの進化に伴って時間とともに変化する可能性があるため、注意が必要です。これを達成する最良の方法は、顧客から報告された問題のトラブルシューティングの標準的な部分として、開発チームに定期的にログを確認する習慣をつけることです。有用なコンテキストを提供しなくなったTraceメッセージをプルーニングし、後続のメッセージのコンテキストを理解するために必要な場所にメッセージを追加することをチームに奨励します。たとえば、表示やタブの変更などのユーザー入力をログに記録すると役立つことがよくあります。
Debug：Debug <Traceを考慮します。違いは、デバッグメッセージがリリースビルドからコンパイルされることです。ただし、デバッグメッセージの使用はお勧めしません。デバッグメッセージを許可すると、追加されるデバッグメッセージが増え、削除されるメッセージがなくなる傾向があります。やがて、ノイズから信号をフィルタリングするのが困難になるため、ログファイルはほとんど役に立たなくなります。これにより、開発者はログを使用しなくなり、死のスパイラルが続きます。対照的に、常にトレースメッセージをプルーニングすると、開発者がそれらを使用するようになり、その結果、高潔なスパイラルが生じます。また、これにより、リリースビルドに含まれていないデバッグコードに必要な副作用が原因で発生するバグの可能性が排除されます。ええ、私はそれが良いコードで起こるべきではないことを知っていますが、より安全で申し訳ありません。
ここに「ロガー」が持っているもののリストがあります。
FATAL：
[ v1.2：..]おそらくアプリケーションを中止させる非常に重大なエラーイベント。
[ v2.0：..]アプリケーションの続行を妨げる重大なエラー。
ERROR：
[ v1.2：..]アプリケーションの実行を継続できるエラーイベント。
[ v2.0：..]アプリケーションにエラーがあり、おそらく回復可能です。
WARN：
[ v1.2：..]潜在的に有害な状況。
[ v2.0：..]可能性のあるイベント[ sic ]がエラーにつながります。
INFO：
[ v1.2：..]大まかなレベルでのアプリケーションの進行状況を強調する情報メッセージ。
[ v2.0：..]情報目的のイベント。
DEBUG：
[ v1.2：..]アプリケーションのデバッグに最も役立つ詳細な情報イベント。
[ v2.0：..]一般的なデバッグイベント。
TRACE：
[ v1.2：..]。より細かい情報イベント
DEBUG。[ v2.0：..]通常、アプリケーションを通過するフローをキャプチャする、きめの細かいデバッグメッセージ。
Apache Httpd（いつものように）は行き過ぎを好む：§
emerg：
緊急事態–システムは使用できません。
警告：
すぐに対処する必要があります[システムはまだ使用可能です]。
クリティカル：
クリティカル条件[ただちに対応する必要はありません]
- " ソケット：ソケットの取得に失敗し、子を終了します "
エラー：
エラー状態[重大ではない]。
- 「スクリプトヘッダーの途中終了」
警告：
警告状態。[エラーに近いが、エラーではない]
注意：
正常ですが、重大な[ 注目すべき ]状態です。
- 「httpd：キャッチされ
SIGBUS、コアをダンプしようとしています...」
情報：
情報提供[および注目すべき]。
- [" サーバーはx時間稼働しています。 "]
デバッグ：
デバッグ・レベル・メッセージ[すなわち、メッセージは、のためにログインデ盗聴）]。
- 「構成ファイルを開いています...」
trace1 → trace6：
トレースメッセージ[つまり、トレースのためにログに記録されたメッセージ]。
- 「プロキシ：FTP：コントロール接続が完了しました」
- " プロキシ：CONNECT：リモートプロキシにCONNECTリクエストを送信します "
- " openssl：ハンドシェイク：開始 "
- " バッファされたSSL旅団から読み取り、モード0、17バイト "
- " マップの検索に失敗しました：
map=rewritemapkey=keyname"- " キャッシュルックアップが失敗しました。新しいマップルックアップを強制します "
trace7 → trace8：
トレースメッセージ、大量のデータのダンプ
- 「
| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |」- 「
| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |」
Apache commons-logging：§
致命的：
途中で終了する重大なエラー。これらがステータスコンソールにすぐに表示されることを期待してください。
エラー：
その他の実行時エラーまたは予期しない状態。これらがステータスコンソールにすぐに表示されることを期待してください。
警告：
廃止されたAPIの使用、APIの不適切な使用、「ほとんど」のエラー、その他の実行時の状況は望ましくない、または予期しないものですが、必ずしも「間違っている」とは限りません。これらがステータスコンソールにすぐに表示されることを期待してください。
情報：
興味深いランタイムイベント（スタートアップ/シャットダウン）。これらがコンソールにすぐに表示されることを期待するので、控えめにして、最小限に留めてください。
デバッグ：
システム内のフローに関する詳細情報。これらがログにのみ書き込まれることを期待してください。
トレース：
より詳細な情報。これらがログにのみ書き込まれることを期待してください。
企業向けのApache Commons-Loggingの「ベストプラクティス」は、デバッグと情報を区別しますどのような境界を越えているかに基づいてをます。
境界は次のとおりです。
外部境界-予期される例外。
外部境界-予期しない例外。
内部境界。
重要な内部境界。
（これについての詳細は、commons-loggingガイドを参照してください。）
問題から回復できる場合は警告です。実行を続行できない場合はエラーです。
fatalErrorでは、ファイルが存在しない場合に関連するアサートを作成するのが慣例です。基本的にそれはあなたが言ったことの反対です。
Syslog重大度レベルを採用することをお勧めしますDEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY。http://en.wikipedia.org/wiki/Syslog#Severity_levelsを
参照してください
ほとんどのユースケースに十分な粒度の重大度レベルを提供する必要があり、既存のログパーサーによって認識されます。もちろん、たとえばDEBUG, ERROR, EMERGENCYアプリの要件に応じて、サブセットのみを実装する自由があります。
私たちが作成するさまざまなアプリごとに独自の基準を思いつくのではなく、古くからあるものを標準化しましょう。ログの集計を開始し、さまざまなログのパターンを検出しようとすると、非常に役立ちます。
DEBUG、INFO、WARNINGとERROR。開発者はすべてのレベルを確認する必要があります。までのSysAdmins INFOとエンドユーザーは警告とエラーを表示できますが、それについて警告するフレームワークがある場合のみです。
DEBUGと同様にTRACE、開発者が粒度を制御します。そして、ERRORのような他のレベルに拡大しCRITICAL、ALERT、EMERGENCYエラーの重大度を区別し、重大度に基づいて行動を決定します。
回復できる警告。できないエラー。それは私のヒューリスティックです、他の人は他のアイデアを持っているかもしれません。
たとえば、名前"Angela Müller"をアプリケーションに入力/インポートするとします（の上のウムラウトに注意してくださいu）。コード/データベースは英語のみである可能性があります（おそらく、この日付と年齢ではないはずです）。したがって、すべての「異常な」文字が通常の英語の文字に変換されたことを警告できます。
その情報をデータベースに書き込もうとして、ネットワークダウンメッセージを60秒間そのまま返すのとは対照的です。これは警告というよりはエラーのほうが多いです。
他の人が言ったように、エラーは問題です。警告は潜在的な問題です。
開発では、アサーションエラーに相当する警告を頻繁に使用しますが、アプリケーションは引き続き機能します。これにより、そのケースが実際に発生したのか、それとも私の想像力であるのかを知ることができます。
しかし、はい、それは回復可能性と現実の側面に行き着きます。回復できる場合は、おそらく警告です。実際に何かが失敗する場合は、エラーです。
SYSLOGレベルのNOTICEとALERT / EMERGENCYは、アプリケーションレベルのログ記録にはほとんど不要であると思います-CRITICAL / ALERT / EMERGENCYは、さまざまなアクションと通知をトリガーする可能性のあるオペレーターにとって有用なアラートレベルですが、アプリケーション管理者にとっては、すべて同じです。致命的。そして、私は通知が与えられるか、いくつかの情報が与えられるかを十分に区別することができません。情報が注目に値しない場合、それは実際には情報ではありません:)
私はジェイシンコッタの解釈が一番好きです。コードの実行を追跡することは、テクニカルサポートで非常に便利です。特に、特定のアプリケーションコンポーネントからのトレースメッセージをログに記録する動的フィルタリングメカニズムと組み合わせて、トレースステートメントをコードに自由に追加することをお勧めします。ただし、デバッグレベルは私がまだ何が起こっているのかを理解している最中であることを示しています。デバッグレベルの出力は、開発ログのみであり、運用ログに表示されるものではありません。
ただし、sysadminの帽子をテクニカルサポートまたは開発者でさえも身に着けているときに、エラーログに表示したいログレベルがあります。OPERは、OPERATIONALメッセージです。これは、タイムスタンプ、呼び出された操作のタイプ、提供された引数、おそらく（一意の）タスク識別子、およびタスクの完了をログに記録するために使用します。これは、たとえばスタンドアロンタスクが起動されたときに使用されます。これは、長時間実行される大きなアプリ内からの真の呼び出しです。これは、何か問題が発生したかどうかに関係なく、常にログに記録したいものです。そのため、OPERのレベルはFATALよりも高いと考えているため、完全にサイレントモードに切り替えないとオフにできません。そしてそれは単なるINFOログデータ以上のものです。ログレベルは、ログにスパムを送信するためにしばしば悪用され、履歴上の価値のない小さな運用メッセージが含まれます。
状況に応じて、この情報は別の呼び出しログに送信される場合や、より多くの情報を記録する大きなログからフィルタリングして取得する場合があります。ただし、履歴情報として、何が行われているかを知ることが常に必要です。AUDITのレベルに下がらないと、誤動作やシステム操作とはまったく関係のない別の完全に独立したログレベルであり、上記のレベルに実際には適合しません（重大度の分類ではなく、独自の制御スイッチが必要なため）、独自の個別のログファイルが必要です。
RFC 5424から、Syslogプロトコル（IETF）-ページ10：
各メッセージの優先度には、10進数の重大度レベルインジケータもあります。次の表で、これらを数値とともに説明します。重大度の値は、0から7までの範囲でなければなりません。
Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Table 2. Syslog Message Severities
私は完全に他の人に同意し、GrayWizardxが最もよく言ったと思います。
私が追加できるのは、これらのレベルは一般的に辞書の定義に対応しているので、それほど難しくはありません。疑問がある場合は、パズルのように扱ってください。特定のプロジェクトについて、ログに記録したいすべてのことを考えてください。
さて、あなたは何が致命的であるかを理解できますか？あなたは致命的な意味を知っていますよね？それで、あなたのリストのどのアイテムが致命的です。
さて、それは致命的な問題です。では、エラーを見てみましょう...すすぎ、繰り返します。
致命的またはおそらくエラーの下で、私はより多くの情報が常により少ないよりも優れていることをお勧めします。情報か警告かわからない？次に、警告します。
致命的で間違いは私たち全員にとって明確であるべきだと私は思います。他はあいまいかもしれませんが、それらを正しくすることは間違いなくそれほど重要ではありません。
ここではいくつかの例を示します。
致命的 -メモリ、データベースなどを割り当てることができません-続行できません。
エラー -メッセージへの応答がない、トランザクションが中止された、ファイルを保存できないなど
警告 -リソースの割り当てがX％（たとえば80％）に達しています-これは、ディメンションを再設定する必要がある可能性があることを示しています。
情報 -ユーザーのログイン/ログアウト、新しいトランザクション、ファイルの作成、新しいd / bフィールド、またはフィールドの削除。
デバッグ -内部データ構造のダンプ、ファイル名と行番号を含むAnything Traceレベル。
トレース-アクションの成功/失敗、d / bの更新。
エラーは間違いであり、明らかに間違っているものであり、回避策はなく、修正する必要があります。
警告はパターンの兆候であり、間違っている可能性がありますが、そうではない可能性もあります。
そうは言っても、エラーではない警告の良い例は思いつきません。つまり、警告をログに記録するというトラブルに行った場合、根本的な問題を修正することもできます。
ただし、「SQLの実行に時間がかかりすぎる」などの警告は発生する可能性がありますが、「SQLの実行のデッドロック」はエラーなので、おそらくいくつかのケースが考えられます。
varchar定義されているよりも多くの文字をに挿入しようとすると、値が切り捨てられたことを警告しますが、それでも挿入します。しかし、ある人の警告は別の人のエラーである可能性があります。私の場合、これはエラーです。これは、データベースと一致しない長さを定義することにより、検証コードでエラーが発生したことを意味します。そして、別のDBエンジンがこれをエラーと見なしたとしても、私はそれほど驚くことはありません。そして、結局のところ、それは誤りです。
私はその前に次のものを使用してシステムを構築しました：
私が構築したシステムでは、管理者はエラーに対応するように指示されていました。一方、警告を監視し、システムの変更、再構成などが必要かどうかをケースごとに判断します。
ところで、私はすべてをキャプチャし、後で情報をフィルタリングするのが大好きです。
警告レベルでキャプチャしていて、警告に関連するデバッグ情報が必要だが警告を再作成できない場合はどうなりますか？
すべてをキャプチャし、後でフィルタリングします！
これは、プロセッサが追いつけないことが判明しない限り、組み込みソフトウェアにも当てはまります。その場合、トレースを再設計して効率を上げるか、トレースがタイミングを妨げている可能性があります（デバッグを検討することを検討する場合があります）より強力なプロセッサですが、それによりワームの缶詰が完全に開きます）。
すべてをキャプチャして後でフィルタリングします!!
（ところで、すべてをキャプチャすると、デバッグトレースを表示するだけでなくツールを開発できるため、優れています（私のメッセージシーケンスチャートとメモリ使用量のヒストグラムを描画します。また、問題が発生した場合の比較の基準にもなります。今後（成功または失敗にかかわらず、すべてのログを保持し、ビルド番号をログファイルに必ず含めてください）。
私の2セントについてFATALとTRACEエラーログレベル。
ERROR 何らかの障害（例外）が発生したときです。
FATAL 実際にはDOUBLE FAULT：例外の処理中に例外が発生した場合。
Webサービスは理解しやすいです。
INFO WARNERRORFATALTRACE関数の入り口/出口をトレースできるときです。このメッセージは一部のデバッガーによって生成される可能性があり、コードがまったく呼び出していないため、これはロギングに関するものではありませんlog。したがって、アプリケーションからのものではないメッセージは、TRACEレベルのようにマークされます。たとえば、次のコマンドでアプリケーションを実行しますstrace
だから、一般的に、あなたのプログラムの中で、あなたが行うDEBUG、INFOおよびWARNログ記録。そして、あなたが使用するのは、いくつかのWebサービス/フレームワークを書いている場合のみですFATAL。また、アプリケーションをデバッグしているときにTRACE、このタイプのソフトウェアからログを取得します。
3つのレベルのみを使用することをお勧めします
noticeこのコレクションで見逃すだろう誰かが見逃すことはありません...