Web アプリケーションを完成させ、ロギングを実装しようとしています。何をログに記録するかの良い例を見たことがありません。ただの例外ですか？ログに記録する必要があるものは他にありますか? バグを見つけて修正するのに役立つと思われる情報の種類を教えてください。
いくつかの具体的なガイダンスとベスト プラクティスを探しています。
ありがとう
ファローアップ
例外をログに記録する場合、具体的にどのような情報をログに記録する必要がありますか? 以上のことをする必要があり_log.Error(ex.Message, ex);ますか？
これは、アプリケーション内でログに記録できるもの、ログを記録したい理由、およびそれを行う方法についての私の論理的な内訳です。実装時にlog4netなどのロギングフレームワークを使用することをお勧めします。
他のすべてが失敗した場合、これはすべきではありません。すべての未処理の例外をキャプチャするための中心的な手段を用意することをお勧めします。これは、スレッド以上のものを使用していない限り、アプリケーション全体を巨大な try/catch でラップするよりもはるかに難しくありません。ただし、例外が届くまで待つと、多くの有用な情報が範囲外になってしまうため、作業はここで終わりではありません。少なくとも、スタックが巻き戻されるときにデバッグに役立つ可能性が高いアプリケーションの状態の特定の部分を収集するようにしてください。アプリケーションは、特に本番環境では、このタイプのログ出力を生成できるように常に準備しておく必要があります。ELMAHをまだご覧になっていない場合は、ぜひご覧ください。私はそれを試したことはありませんが、私は素晴らしいことを聞きました
私がアプリケーション ログと呼んでいるものには、「削除された注文」や「ユーザーがサインオンした」などの概念レベルでアプリケーションが行っていることに関する情報をキャプチャするログが含まれます。この種の情報は、傾向の分析、システムの監査、システムのロックダウン、テスト、セキュリティ、おおざっぱなバグの検出に役立ちます。これらのログを本番環境にも残すことを計画することは、おそらく良い考えです。おそらく、さまざまなレベルの粒度で。
私にとって、トレース ロギングは、ロギングの最も詳細な形式を表しています。このレベルでは、アプリケーションが何を行っているかよりも、どのようにそれを行っているかに焦点を当てます。これは、コードを 1 行ずつ実際に見ていく上での 1 ステップです。おそらく、並行性の問題や、再現が困難な問題に対処するのに最も役立ちます。これを常に実行しておく必要はなく、おそらく必要なときにのみオンにします。
最後に、通常は最後に対処するだけの他の多くの事柄と同様に、ロギングについて考えるのに最適な時期はプロジェクトの開始時です。これにより、アプリケーションを念頭に置いて設計することができます。素晴らしい質問ですが！
ログに記録するもの：
ログに記録しないためのいくつかの事柄：
アプリケーションとその対象者によって異なります。株式の販売や取引を管理している場合は、個人のブログよりも多くの情報を記録する必要があります。ログが最も必要なのは、実稼働環境でエラーが発生しているが、ローカルでそれを再現できない場合です。ログレベルとログ階層があると、ログレベルを動的に上げることができるため、このような状況で役立ちます。log4jのドキュメントとlog4netを参照してください。
アプリケーションでまだ定義されていないが、クライアントから要求されたページ/リソースへのアクセスをログに記録する必要があるかもしれません。そうすれば、脆弱性を見つけることができるかもしれません。
例外をログに記録するときは、現在の日時、要求された URL、URL リファラー、およびユーザーの IP アドレスも保存する必要があると思います。
おそらく、この段階ではこれについて考えるべきではありません。むしろ、潜在的なバグが発生する前にそれを拡散するために、開発のあらゆる段階でロギングを検討することが役立ちます。プログラムによっては、できるだけ多くの情報をキャプチャしようとします。すべてをログに記録します。データを十分に参照していない場合は、特定のコンポーネントまたはプロセスのログ記録をいつでも停止できます。情報が多すぎるということはありません。
私の (限られた) 経験から、考えられるエラーの種類ごとに特定のエラー テーブルを作成したくない場合は、一般的な情報と、例外データを入力できる文字列を受け入れる一般的なデータベース テーブルを作成します。成功しているが重要なプロセスなど。これには、パラメーターを持つ汎用関数を使用しました。
必要に応じて、ログをオフにする機能も検討する必要があります。
お役に立てれば。
私の数セント。ログの重大度と例外を適切に使用するだけでなく、ログ ステートメントを構造化して、後でログ データを簡単に確認できるようにすることを検討してください。たとえば、意味のある情報をすばやく抽出したり、クエリを実行したりします。大量のログ データを生成することに問題はありません。問題は、このデータを情報に変換することです。したがって、事前に構造化して定義しておくと、後で使用するのに役立ちます。log4j を使用する場合は、マップされた診断コンテキスト (MDC) を使用することもお勧めします。これは、セッション コンテキストの追跡に非常に役立ちます。トレースと情報以外に、通常は一時的に保持するデバッグ レベルも使用します。アイテム。これらは、不要な場合は除外するか、無効にすることができます。