3

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

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

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

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

私が方法で気をつけるべき落とし穴を知っていますか？

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

アップデート：

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

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

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

4

5 に答える 5

3

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

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

于 2009-01-04T17:52:09.060 に答える
2

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

ロギングに関しては、現時点で log4net に勝るものはありません。

于 2009-01-04T17:57:22.327 に答える
2

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

  • 使用 protected void Application_Error(object sender, EventArgs e) { Server.Transfer("~/Support/ServerErrorSupport.aspx", true); } (Server.Transferすべての投稿データを保持するために a を実行します。)

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

  • 次のすべてのデータを xml 構造に記録します (データ型に応じて、値の格納方法が異なります。値の型 => ToString()、ISerializable => シリアライズ、...):

    1. マシン名: Application.Server.MachineName
    2. PhysicalRoot: Application.Server.MapPath("~/")
    3. RequestUrl: Application.Request.Url.ToString()
    4. アプリケーション設定: WebConfigurationManager.AppSettings
    5. ConnectionSettings: WebConfigurationManager.ConnectionStrings
    6. クエリ文字列: Application.Request.QueryString
    7. フォームポスト: Application.Request.Form
    8. セッション: Application.Session
    9. HttpHeaders: Application.Request.Headers

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

    • rapport (xml ファイル) を自分宛てにメールで送信できます (テスト/デバッグ中は非常に簡単です)。
    • 本番中にローカルまたはデータベースに保存する
    • ファイルは単なる (hd へのダンプ) 保存であるため、エラー レポートの作成中に問題が発生する可能性はほとんどありません (サーバー接続、データベースの問題など)。書き込み権限があることを確認してください。
    • さらに、servererrorsupport.aspx ページで、xml ファイルを保存した後、ユーザーは追加情報を含めたり、バグに関する進行状況を最新の状態に保つために電子メール アドレスを追加したりするオプションを取得します。これは、xml ドキュメントに追加されます。
    • xslt ファイルを使用して、適切なエラー レポートのエラー データ (xml) をフォーマットします。
于 2009-01-05T01:36:17.827 に答える
1

エラーについては、私はたくさんのログを記録するのが大好きです。物事がうまくいかないとき、情報は非常に価値があります。関連するイベントをグループ化するために、セッションIDを使用してログ全体を1つの場所（テキストファイルまたはデータベーステーブル）に保持します。

于 2009-01-04T17:24:56.383 に答える
1

私がログに記録したいものは次のとおりです。

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

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

面白い話: ある時、データベースにログを記録するエラー ロガーがありましたが、データベースの資格情報が間違っていたため、エラーが発生し、ログに記録されました... 再帰 (IIRC) からスタック オーバーフローが発生しました。

于 2009-01-04T18:02:58.180 に答える