エラー処理やログ記録がまったくない3.5の新しいasp.netサイトを見ています。エラーをログに記録して処理するためのいくつかの良いオプションは何ですか?1.1フレームワークでLog4Netを使用しましたが、3.5には潜在的に優れたオプションがあると聞きました。
6 に答える
1 つのオプションは ELMAH です。ここで質問しました: ASP.NET Error Handling。
それ以来、わずかに変更したバージョンを実装しました。ロギングと電子メールは優れており、web.config ファイルを介して簡単に統合できます。
ロギングには2つのオプションを使用します。-
予期しない例外処理のためのELMAH
予想される手動(デバッグ、情報、およびエラー)情報のNLog 。
ELMAHは、例外(404(ページが見つかりません)から500の例外がスローされるまで)を自動的にキャプチャし、これらのエラーを視覚化するための組み込みのWebUIを備えた優れたすぐに使えるプラグインです。したがって、これは、発生する予期しないエラーを取得するための非常に迅速で効果的な方法です。
現在、 NLogは、開発者が特定の場所でコードにデバッグ情報を手動で挿入することでこれを 補完しているため、非ロカホストシステムから情報を取得する必要がある場合は非常に簡単です。たとえばlog.Debug(..)
、ほとんどのメソッドでコードを散らかして、ローカル変数や戻り値などを確認します。さらに重要な情報については、log.Info(..)
..を使用しますが、これはあまり使用しません。最後に、トラップして処理した重大なエラーについては、log.Error(..)
またはlog.Warn(..)
..一般的に一部のtry/catch
スコープ内で使用します。Debug
したがって、テストサーバーまたはライブサーバーでは、大量のデータを取得する必要がある場合、ライブ...または状態などの一般的な重要な情報のみを取得する必要がある場合は、すべてのログ状態(およびそれ以上)をオンにしInfo
ます。私たちはいつも持っていますWarn, Error and Fatal
常にオンになっています。デバッグ状態は大量のデータを生成するため、それは控えめに使用します。
要約すると、WebAppには2つのアプローチを使用することをお勧めします。予期しないエラートラップに優れたElmahと、予想される情報とエラーに対応するNLog。
最後に、NLogはLog4Netよりも使いやすく/動作しやすいです。それは基本的にそれよりも優先されます、IMO。
log4net に慣れている場合は、知っていることを守ってください。簡単で、速く、うまく機能します。1.1、2.0、そして現在は 3.5 で何年も使用しています。
ASP.NET ヘルス モニタリングは、実際にはすぐに使用できる優れた機能を備えています。
Enterprise Libraryには学習曲線があるかもしれませんが、優れたプロジェクトです。
Asp.Net では、david hayden の記事Enterprise Library 2.0 Logging Application Blockに従ってください。
個人的には、log4net を試したことはありませんが、winforms の仕様と例を見ましたが、私の組織は、スタック トレース、セッション (存在する場合)、フォームの NVC、アプリのバージョン、クエリ文字列でエラーを発生させた URL、および HTTP ヘッダー。すべてのエラーがそこに記録されるわけではないことに気付きましたが。フォーム認証の有効期限、アプリケーション プールの再起動/シャットダウン、または実行中のアプリケーションによってスローされなかった IIS によって報告されたものなど。