エラーからログに記録する情報量[閉まっている]

StackOverflow https://stackoverflow.com/questions/411312

  •  03-07-2019
  •  | 
  •  

質問

勤務先の会社で、ASP.netアプリケーションのエラーを処理するためのエラーログクラスを作成しました。サーバーに追加のソフトウェア（nLog、log4netなど）をインストールすることは許可されていないため、カスタムクラスです。

現在、2つのプロジェクトで使用していますが、いくつかの良い結果が得られています。現在、ページとアプリケーションのエラーを引き起こすエラーをトラップしています。エラーメッセージとすべての内部例外を送信して保存します。

私が現在抱えている問題は、再現方法がよくわからないというエラーを受け取っていることです。ユーザーからエラー報告を聞いたことはありません。彼らが何をしているのか、あるいは彼らがこれらをエラーとして見ているのかどうかはわかりません。

各ページでイベントログを作成するか、追加情報が必要なものを作成することを検討しています。ページ上のセッション変数として保持し、イベントを書き込みます（関数の開始/終了、変数の変更など）。次に、エラーが呼び出されて、エラーメッセージと一緒に送信され、何が起こっているのかをより正確に把握できるかどうかを確認します。この方法ですべてのユーザーがアプリケーションにアクセスするときに大量のイベントログが表示されないことを望んでいます。1人のユーザーでエラーが発生する直前に実行したいだけです。

メソッドで注意する必要がある落とし穴を知っていますか？

探すべきことについてアドバイスはありますか？

更新：

@Saret：その回答であなたがどこから来たのかを理解し、同意します。私はこの会社にはかなり新しいのですが、彼らが物事をどのように行うかをまだ学ぶ必要があります。過去に、この製品を手に入れるか、このオープンソースプロジェクトを使用するのが素晴らしいと同僚と話しました。問題は、安全なシステムに取り組んでおり、これらを取得するための承認を得るには多くの時間、トップカバー、すべての赤テープの処理が必要です。適切なエラーログシステムを適切に配置することが重要であり、現在は何も使用されていないため、状況をさらに詳しく調べます。

@Jim Blizard：どこかに戻ってエラーの原因となった状況で何が重要かを知るために、どこかですべてを記録/保存することを避けたいと思いました。ロベルト・バロスがリンクしたアーティカルで語られる情報の過負荷に陥りたくありませんでした。私の現在の考え方は、各ページの文字列をメモリに保持し、ページのPage_Errorイベントでエラーが発生した場合、その文字列を取得して、ログに記録される例外に添付します。そのようにして、発生したエラー/例外のみを記録し、そのエラーとともにイベントログを保存しています。何も起こらない場合、作成されていたログはビットバケットにドロップされ、再び表示されることはありません。

@Roberto Barros：そのリンクをありがとう、どこかで読んだことを覚えているが、保存するのを忘れた。

役に立ちましたか？

解決

これは、あなたが探している正確な答えではないかもしれませんが、これらの重要な問題をすべて処理する強力なツール（言及している）があるのに、なぜ独自のエラーロギングメカニズムを開発するのですか？

追加のソフトウェアをインストールすることは許可されていませんが、カスタムコードのようなクラスだけをライブラリに記録しているわけではありません。基本的な違いはどこですか？ロギングフレームワークの実装について心配するのに費やす時間は、適切なロギングソリューションのビジネスケースを提唱し、作成することに費やす方が良いと思います。

他のヒント

以前は、純粋に自分のコードまたはそれらの（恐ろしい）COMオブジェクトではないもののインストールを許可しない機関で働いていました。このタイプの制限がある場合は、log4netのソースを取得してプロジェクトに含めることができるかどうかを確認してください。

現在、ロギングに関してはlog4netより優れたものはありません。

私は個人的に、asp.netアプリケーションでのエラー（およびエラーのみのログ）の記録に関して次のアプローチを取りました。

  • 使用 <コード> protected void Application_Error（オブジェクト送信者、EventArgs e） {     Server.Transfer（＆quot;〜/ Support / ServerErrorSupport.aspx＆quot ;, true）; } （すべての投稿データを保持するために Server.Transfer を実行します。）

  • このエラーに固有のエラーIDを生成します（したがって、同じエラーの後続のrepportをグループ化できます）。 IDは、file、method、lineNr、error.Messageで構成される連結文字列から計算されたハッシュです。スタックトレースの正規表現を使用して、ファイル、メソッド、およびlineNrの値を取得します。

  • 次のすべてのデータをxml構造体に記録します（データ型に応じて、値を別々に保存します、値型=＆gt; ToString（）、ISerializable =＆gt; serialize、...）：

    1. MachineName：Application.Server.MachineName
    2. PhysicalRoot：Application.Server.MapPath（＆quot;〜/＆quot;）
    3. RequestUrl：Application.Request.Url.ToString（）
    4. ApplicationSettings：WebConfigurationManager.AppSettings
    5. ConnectionSettings：WebConfigurationManager.ConnectionStrings
    6. QueryString：Application.Request.QueryString
    7. FormPost：Application.Request.Form
    8. セッション：Application.Session
    9. HttpHeaders：Application.Request.Headers

  • エラーIDとタイムスタンプを含むローカルファイルとしてxml構造を保存します。 このアプローチを選んだ理由は：

    • ラポート（xmlファイル）を自分にメールで送信できます（テスト/デバッグ中は非常に簡単です）
    • 本番中にローカルまたはデータベースに保存する
    • ファイルは（hdへのダンプ）保存であるため、エラーレポートの作成中（サーバー接続、dbの問題など）に問題が発生することはほとんどないため、書き込み権限があることを確認してください。
    • さらに、servererrorsupport.aspxページで、xmlファイルを保存した後、ユーザーは追加情報を追加し、バグに関する進行状況を更新するために電子メールアドレスを追加するオプションを取得します。これはxmlドキュメントに追加されます。
    • xsltファイルを使用して、エラーレポート（xml）を素敵なエラーレポートにフォーマットします。

エラーについては、私はA LOTのロギングが大好きです。物事がうまくいかないとき、情報は非常に貴重です。ログ全体を1つの場所（テキストファイルまたはデータベーステーブル）に保持し、セッション識別子を使用して、関連するイベントをグループ化します。

ここに私が記録したいものがあります：

  • エラー/デバッグレベル（情報、デバッグ、問題、クラッシュなど）
  • 時間
  • 説明テキスト（通常は1行）
  • スタックトレース（可能な場合）
  • データ（ユーザー、セッション、変数値など）

最も簡単な方法はテキストファイルに書き込むことですが、データベースに保存しておくと便利です。 Windowsイベントログを使用することもできます。気をつけるべきことがいくつかあります。うーん...定期的にログを消去する必要があります。

おもしろい話：かつてデータベースにログを記録するエラーロガーがありましたが、データベースクレデンシャルが悪かったためにエラーが発生しました...再帰（IIRC）からスタックオーバーフローが発生しました。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top