致命的な順に、メッセージをログに記録するさまざまな方法があります。
FATALERRORWARNINFODEBUGTRACE
いつどちらを使用するかをどのように決定しますか？
使用するのに適したヒューリスティックは何ですか？
449234 次
20 に答える
978
私は通常、次の規則に同意します。
- トレース-コードを「トレース」して、関数の一部を具体的に見つけようとする場合のみ。
- デバッグ-開発者（IT、システム管理者など）だけでなく、診断に役立つ情報。
- 情報-ログに記録する一般的に役立つ情報（サービスの開始/停止、構成の前提条件など）。情報私は常に利用できるようにしたいのですが、通常の状況では気にしません。これは、すぐに使用できる構成レベルです。
- 警告-アプリケーションの奇妙さを引き起こす可能性があるが、自動的に回復しているもの。（プライマリサーバーからバックアップサーバーへの切り替え、操作の再試行、セカンダリデータの欠落など）
- エラー-操作に致命的であるが、サービスまたはアプリケーションには致命的ではないエラー（必要なファイルを開くことができない、データが欠落しているなど）。これらのエラーは、ユーザー（管理者または直接ユーザー）の介入を強制します。これらは通常、誤った接続文字列、不足しているサービスなどのために（私のアプリで）予約されています。
- 致命的-データ損失（またはさらなるデータ損失）を防ぐためにサービスまたはアプリケーションのシャットダウンを強制するエラー。私はこれらを、データの破損または損失が保証されている最も凶悪なエラーおよび状況のためにのみ予約します。
于 2010-01-08T22:26:35.737 に答える
338
深夜にシステム管理者をベッドから出してもらうようにメッセージを送信しますか？
- はい->エラー
- いいえ->警告
于 2010-01-08T22:23:41.260 に答える
160
ログファイルを表示するという観点から、重大度について考える方が便利だと思います。
致命的/重大：アプリケーション全体またはシステム障害。すぐに調査する必要があります。はい、SysAdminを起動します。SysAdminsアラートを優先し、十分に休息しているため、この重大度は非常にまれにしか使用されません。それが毎日起こっていて、それがBFDでない場合、それはその意味を失います。通常、致命的なエラーはプロセスの存続期間中に1回だけ発生するため、ログファイルがプロセスに関連付けられている場合、これは通常、ログの最後のメッセージです。
エラー：間違いなく調査する必要のある問題です。SysAdminは自動的に通知されるはずですが、ベッドからドラッグする必要はありません。ログをフィルタリングしてエラーを確認することにより、エラーの頻度の概要を把握し、追加のエラーのカスケードを引き起こした可能性のある開始障害をすばやく特定できます。エラー率をアプリケーションの使用状況と比較して追跡すると、全体的な品質を評価するために使用できるMTBFなどの有用な品質メトリックが得られます。たとえば、このメトリックは、リリース前に別のベータテストサイクルが必要かどうかについての決定を通知するのに役立つ場合があります。
警告：これは問題になる可能性がありますが、そうでない可能性があります。たとえば、ネットワークやデータベース接続の短期間の喪失など、予想される一時的な環境条件は、エラーではなく警告としてログに記録する必要があります。警告とエラーのみを表示するようにフィルタリングされたログを表示すると、後続のエラーの根本原因に関する初期のヒントをすばやく把握できる場合があります。警告は、意味がなくなることがないように、慎重に使用する必要があります。たとえば、ネットワークアクセスの喪失は、サーバーアプリケーションでは警告またはエラーである必要がありますが、ラップトップユーザーがときどき切断されるように設計されたデスクトップアプリでは単なる情報である可能性があります。
情報：これは、初期化の成功、サービスの開始と停止、重要なトランザクションの正常な完了など、通常の状態でログに記録する必要がある重要な情報です。情報以上を示すログを表示すると、プロセスの主要な状態変化の概要がわかり、発生する警告やエラーを理解するためのトップレベルのコンテキストが提供されます。情報メッセージが多すぎないようにしてください。通常、トレースに比べて5％未満の情報メッセージがあります。
トレース：トレースは、これまでで最も一般的に使用される重大度であり、エラーや警告に至るまでの手順を理解するためのコンテキストを提供する必要があります。トレースメッセージの密度を適切に設定すると、ソフトウェアの保守性が大幅に向上しますが、プログラムの進化に伴って個々のトレースステートメントの値が時間とともに変化する可能性があるため、ある程度の注意が必要です。これを実現する最善の方法は、顧客から報告された問題のトラブルシューティングの標準的な部分として、開発チームにログを定期的に確認する習慣をつけることです。チームに、有用なコンテキストを提供しなくなったトレースメッセージを整理し、後続のメッセージのコンテキストを理解するために必要な場所にメッセージを追加するように促します。たとえば、表示やタブの変更などのユーザー入力をログに記録すると役立つことがよくあります。
デバッグ：デバッグ<トレースと見なします。違いは、デバッグメッセージがリリースビルドからコンパイルされることです。とはいえ、デバッグメッセージの使用はお勧めしません。デバッグメッセージを許可すると、追加されるデバッグメッセージが増え、削除されるメッセージがなくなる傾向があります。やがて、ノイズから信号をフィルタリングするのが難しすぎるため、ログファイルはほとんど役に立たなくなります。そのため、開発者はログを使用せず、死のスパイラルが続きます。対照的に、トレースメッセージを絶えず整理すると、開発者はそれらを使用するようになり、好意的なスパイラルが発生します。また、これにより、リリースビルドに含まれていないデバッグコードに必要な副作用が原因でバグが発生する可能性がなくなります。ええ、私はそれが良いコードで起こるべきではないことを知っていますが、より安全で申し訳ありません。
于 2011-03-11T20:33:36.233 に答える
70
これは古いトピックですが、それでも関連性があります。今週、私は同僚のためにそれについての小さな記事を書きました。そのために、オンラインで何も見つからなかったので、このチートシートも作成しました。
于 2020-11-12T15:24:29.373 に答える
43
これが「ロガー」が持っているもののリストです。
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、コアダンプを試みています... "
- " httpd：キャッチ
情報：
情報提供[そして注目に値しない]。
- ["サーバーは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コモンズ-ロギング：§
致命的：
早期終了の原因となる重大なエラー。これらはステータスコンソールにすぐに表示されることを期待してください。
エラー：
その他のランタイムエラーまたは予期しない状態。これらはステータスコンソールにすぐに表示されることを期待してください。
警告：
非推奨のAPIの使用、APIの不適切な使用、「ほぼ」エラー、望ましくないまたは予期しないその他の実行時の状況。ただし、必ずしも「間違っている」とは限りません。これらはステータスコンソールにすぐに表示されることを期待してください。
情報：
興味深いランタイムイベント（起動/シャットダウン）。これらはコンソールにすぐに表示されることを期待しているので、控えめにして最小限に抑えてください。
デバッグ：
システムを通過するフローに関する詳細情報。これらはログにのみ書き込まれることを期待してください。
トレース：
より詳細な情報。これらはログにのみ書き込まれることを期待してください。
Apacheコモンズ-エンタープライズで使用するためのログ記録の「ベストプラクティス」は、それらがどのような境界を越えるかに基づいて、デバッグと情報を区別します。
境界は次のとおりです。
外部境界-予想される例外。
外部境界-予期しない例外。
内部境界。
重要な内部境界。
（これについての詳細は、 commons-loggingガイドを参照してください。）
于 2016-04-15T20:14:00.503 に答える
27
Syslogの重大度レベルを採用することをお勧めしますDEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY。http://en.wikipedia.org/wiki/Syslog#Severity_levels
を参照してください
これらは、ほとんどのユースケースに十分なきめ細かい重大度レベルを提供する必要があり、既存のログパーサーによって認識されます。もちろん、たとえばDEBUG, ERROR, EMERGENCYアプリの要件に応じて、サブセットのみを実装する自由があります。
私たちが作るさまざまなアプリごとに独自の標準を考え出すのではなく、何年も前から存在しているものを標準化しましょう。ログの集計を開始し、さまざまなログのパターンを検出しようとすると、非常に役立ちます。
于 2013-01-08T07:56:34.670 に答える
26
問題から回復できる場合、それは警告です。それが実行の継続を妨げる場合、それはエラーです。
于 2010-01-08T22:22:52.617 に答える
21
回復できる警告。あなたができないエラー。それは私のヒューリスティックです、他の人は他のアイデアを持っているかもしれません。
たとえば、名前"Angela Müller"をアプリケーションに入力/インポートするとします（上のumlautに注意してくださいu）。コード/データベースは英語のみである可能性があり（おそらくこの時代にはないはずですが）、したがって、すべての「異常な」文字が通常の英語の文字に変換されたことを警告できます。
それとは対照的に、その情報をデータベースに書き込もうとして、ネットワークダウンメッセージを60秒間続けて返してください。これは警告というよりはエラーです。
于 2010-01-08T22:22:48.937 に答える
7
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
于 2017-04-11T16:06:59.340 に答える
7
Taco Jan Osingaの答えは、起動するのに非常に優れており、非常に実用的です。
いくつかのバリエーションはありますが、私は彼と部分的に同意しています。
Pythonでは、「名前付き」のログレベルは5つしかないため、次のように使用します。
DEBUG-トラブルシューティングに重要な情報であり、通常、通常の日常業務では抑制されますINFO-プログラムが設計どおりに機能を実行していることの「証拠」としての日常業務WARN-名目上ではないが回復可能な状況、または*または*将来の問題を引き起こす可能性のある何かに遭遇した場合ERROR-プログラムでリカバリを実行する必要がある何かが発生しましたが、リカバリは成功しています。ただし、プログラムは当初期待されていた状態ではない可能性が高いため、プログラムのユーザーは適応する必要がありますCRITICAL-回復できない何かが起こったので、誰もが罪の状態で生きないように、プログラムを終了する必要があるでしょう。
于 2020-12-04T03:30:23.017 に答える
6
他の人が言っているように、エラーは問題です。警告は潜在的な問題です。
開発では、アサーションの失敗に相当する警告を頻繁に使用しますが、アプリケーションは引き続き機能します。これにより、そのケースが実際に発生したかどうか、またはそれが私の想像であるかどうかを知ることができます。
しかし、はい、それは回復可能性と現実の側面に帰着します。回復できる場合は、おそらく警告です。それが実際に何かを失敗させる場合、それはエラーです。
于 2010-01-08T22:32:09.543 に答える
6
私は他の人たちに完全に同意し、GrayWizardxがそれを最もよく言ったと思います。
追加できるのは、これらのレベルは一般に辞書の定義に対応しているため、それほど難しいことではありません。疑わしい場合は、パズルのように扱ってください。特定のプロジェクトについて、ログに記録する可能性のあるすべてのことを考えてください。
さて、あなたは何が致命的かもしれないかを理解できますか？あなたは致命的な意味を知っていますね？したがって、リストのどのアイテムが致命的です。
さて、それは致命的な対処です。では、エラーを見てみましょう...すすぎ、繰り返します。
致命的、またはおそらくエラーの下では、より多くの情報が常により少ないよりも優れていることを示唆しているので、「上向き」に誤ります。情報なのか警告なのかわからない？次に、それを警告にします。
致命的でエラーは私たち全員にとって明らかなはずだと私は思います。他のものはもっと曖昧かもしれませんが、それらを正しくすることは間違いなくそれほど重要ではありません。
ここではいくつかの例を示します。
致命的-メモリやデータベースなどを割り当てることができません-続行できません。
エラー-メッセージへの応答がない、トランザクションが中止された、ファイルを保存できないなど。
警告-リソース割り当てがX％（たとえば80％）に達しました-これは、再ディメンション化する必要がある可能性があることを示しています。
情報-ユーザーのログイン/ログアウト、新しいトランザクション、ファイルの作成、新しいd / bフィールド、またはフィールドの削除。
デバッグ-内部データ構造のダンプ、ファイル名と行番号を含む任意のトレースレベル。
トレース-アクションは成功/失敗し、d/bが更新されました。
于 2010-01-10T00:40:27.630 に答える
5
SYSLOGレベルのNOTICEとALERT/EMERGENCYは、アプリケーションレベルのロギングにはほとんど不要だと思いますが、CRITICAL / ALERT / Emergencyは、さまざまなアクションや通知をトリガーする可能性のあるオペレーターにとって有用なアラートレベルである可能性がありますが、アプリケーション管理者にとってはすべて同じです。致命的。そして、私は通知を与えられているのか、いくつかの情報を与えられているのかを十分に区別することができません。情報が注目に値しない場合、それは実際には情報ではありません:)
私はJayCincottaの解釈が一番好きです-コードの実行をトレースすることはテクニカルサポートで非常に役立つものであり、トレースステートメントをコードに自由に入れることをお勧めします-特に特定のアプリケーションコンポーネントからのトレースメッセージをログに記録するための動的フィルタリングメカニズムと組み合わせて。ただし、私にとってのDEBUGレベルは、何が起こっているのかをまだ把握している途中であることを示しています。DEBUGレベルの出力は、本番ログに表示されるはずのオプションではなく、開発専用のオプションであると考えています。
ただし、システム管理者の帽子をかぶったときに、技術サポートや開発者の帽子をかぶったときにエラーログに表示したいログレベルがあります。OPERATIONALメッセージの場合はOPERです。これは、タイムスタンプ、呼び出された操作のタイプ、提供された引数、場合によっては（一意の）タスク識別子、およびタスクの完了をログに記録するために使用します。これは、たとえばスタンドアロンタスクが実行されるときに使用されます。これは、より大きな長時間実行アプリ内からの真の呼び出しです。何か問題があったかどうかに関係なく、常にログに記録したいので、OPERのレベルはFATALよりも高いと考えているので、完全にサイレントモードに移行することによってのみオフにすることができます。そして、それは単なるINFOログデータ以上のものです。ログレベルは、履歴値がまったくないマイナーな操作メッセージを含むログをスパムするために悪用されることがよくあります。
場合によっては、この情報は別の呼び出しログに送信される場合もあれば、より多くの情報を記録する大きなログからフィルターで除外することによって取得される場合もあります。しかし、履歴情報として、何が行われていたかを知る必要があります-AUDITのレベルに下がることなく、誤動作やシステム操作とは関係のない別の完全に別個のログレベルは、実際には上記のレベルに収まりません（重大度の分類ではなく、独自の制御スイッチが必要であり、独自の個別のログファイルが確実に必要になるためです。
于 2014-06-18T17:24:10.203 に答える
4
G'day、
この質問の結果として、ログレベルの解釈を伝え、プロジェクトのすべての人がレベルの解釈に一致していることを確認します。
重大度と選択したログレベルに一貫性がない多種多様なログメッセージを見るのは辛いことです。
可能であれば、さまざまなロギングレベルの例を提供してください。また、メッセージに記録する情報に一貫性を持たせてください。
HTH
于 2010-01-08T22:40:53.913 に答える
3
エラーとは、間違っている、明らかに間違っている、それを回避する方法がない、修正する必要があるものです。
警告は、パターンが間違っている可能性があることを示していますが、そうでない場合もあります。
そうは言っても、エラーではない警告の良い例を思いつくことはできません。つまり、警告のログ記録に問題が発生した場合は、根本的な問題を修正した方がよいということです。
ただし、「SQLの実行に時間がかかりすぎる」などの警告が表示される場合がありますが、「SQLの実行のデッドロック」はエラーであるため、結局のところ、場合によっては発生する可能性があります。
于 2010-01-08T22:24:19.853 に答える
3
私は常に最初のログレベルに警告することを検討してきましたが、これは確かに問題があることを意味します（たとえば、構成ファイルが本来あるべき場所にないため、デフォルト設定で実行する必要があります）。エラーは、私にとって、ソフトウェアの主な目的が現在不可能であることを意味する何かを意味し、私たちはきれいにシャットダウンしようとしています。
于 2010-01-08T22:28:47.597 に答える
3
私の2セントFATALとTRACEエラーログレベル。
ERROR何らかのFAULT（例外）が発生したときです。
FATAL実際にはDOUBLEFAULTです：例外の処理中に例外が発生した場合。
Webサービスについては理解しやすいです。
- リクエストが来ます。イベントはとしてログに記録されます
INFO - システムがディスク容量の不足を検出しました。イベントはとしてログに記録されます
WARN - リクエストを処理するためにいくつかの関数が呼び出されます。ゼロによる除算の処理中に発生します。イベントはとしてログに記録されます
ERROR - Webサービスの例外ハンドラーは、ゼロによる除算を処理するために呼び出されます。Webサービス/フレームワークは電子メールを送信しますが、メールサービスが現在オフラインであるため送信できません。Webサービスの例外ハンドラーは例外を処理できないため、この2番目の例外は正常に処理できません。
- 別の例外ハンドラが呼び出されました。イベントはとしてログに記録されます
FATAL
TRACE関数の開始/終了をトレースできるときです。このメッセージは一部のデバッガーによって生成される可能性があり、コードがまったく呼び出していないため、これはロギングに関するものではありませんlog。したがって、アプリケーションからのものではないメッセージは、TRACEレベルのようにマークされます。たとえば、アプリケーションを次のように実行しますstrace
したがって、一般的に、プログラムではDEBUG、ログINFOを記録します。WARNそして、あなたがいくつかのウェブサービス/フレームワークを書いている場合にのみ、あなたはを使用しますFATAL。また、アプリケーションをデバッグしているときはTRACE、このタイプのソフトウェアからログを取得します。
于 2020-02-22T14:12:51.170 に答える
1
その前に、次を使用してシステムを構築しました。
- エラー-何かが深刻に間違っており、特定のスレッド/プロセス/シーケンスを続行できないことを意味します。ユーザー/管理者の介入が必要です
- 警告-何かが正しくありませんが、プロセスは以前と同じように続行できます（たとえば、100のセットの1つのジョブが失敗しましたが、残りは処理できます）
私が構築したシステムでは、管理者はエラーに対応するように指示されていました。一方、警告を監視し、それぞれの場合について、システムの変更、再構成などが必要かどうかを判断します。
于 2010-01-08T22:23:10.387 に答える
1
ところで、私はすべてをキャプチャし、後で情報をフィルタリングするのが大好きです。
警告レベルでキャプチャしていて、警告に関連するデバッグ情報が必要であるが、警告を再作成できなかった場合はどうなりますか？
すべてをキャプチャして、後でフィルタリングします。
これは、プロセッサが追いつかない場合を除いて、組み込みソフトウェアにも当てはまります。その場合は、トレースを再設計して効率を上げるか、トレースがタイミングを妨げている可能性があります（より強力なプロセッサですが、それはワームの缶全体を開きます）。
すべてをキャプチャし、後でフィルタリングします!!
（ところで、デバッグトレースを表示するだけでなく、ツールを開発できるため、すべてをキャプチャすることもできます（私は自分のメッセージシーケンスチャートとメモリ使用量のヒストグラムを描画します。また、何か問題が発生した場合の比較の基礎も提供します。 future（合格か不合格かにかかわらず、すべてのログを保持し、ログファイルにビルド番号を必ず含めてください））。
于 2010-01-10T00:48:18.813 に答える
-3
3つのレベルのみを使用することをお勧めします
- 致命的-アプリケーションを壊してしまいます。
- 情報-情報
- デバッグ-それほど重要ではない情報
于 2019-08-28T10:30:55.570 に答える