例外のエラーログを管理する最良の方法は何ですか？

前書き

ウェブサイトまたはシステムでエラーが発生した場合は、ログに記録し、エラーの参照コードを含む丁寧なメッセージをユーザーに表示することはもちろん役立ちます。

また、システムがたくさんある場合は、この情報を点在させたくはありません-単一の集中化された場所を用意しておくとよいでしょう。

最も単純なレベルでは、必要なのは、増分IDとエラーの詳細のシリアル化されたダンプだけです。（そして、おそらく「集中化された場所」は電子メールの受信トレイです。）

スペクトルのもう一方の端には、おそらく完全に正規化されたデータベースがあり、ボタンを押して1日あたりのエラーのグラフを表示したり、システムXで最も一般的なタイプのエラーを特定したりできます。サーバーBよりも接続エラーなど。

ここで言及しているのは、リモートシステムによるコードレベルのエラー/例外のログです。Jira、Tracなどで行われるような「人間ベース」の問題追跡ではありません。

ご質問

このタイプのシステムを使用した開発者から、特に次の点についての考えを探しています。

• 欠かせない基本的な機能は何ですか？
• 本当に時間を節約する機能があると便利ですか？
• どの機能が良いアイデアに思えるかもしれませんが、実際にはそれほど便利ではありませんか？

たとえば、エラーの複数の発生を識別する「重複の表示」機能（「重要でない」詳細が異なることを心配せずに）は非常に重要です。
[このエラーに対して[Jira / etc]で問題を作成する]ボタンは、時間の節約になります。

繰り返しになりますが、私が望んでいるのは、そのようなシステムを使用した人々からの実践的な経験であり、できれば機能が素晴らしい/ひどい理由を裏付けています。
（とにかく理論化するつもりなら、少なくともそのようなものとしてあなたの答えをマークしてください。）

私はMicrosoft Enterpriseライブラリを使用してクライアントエラーを記録したプロジェクトに参加しました。メールボックスに送信するすべての例外。メールの件名に、メッセージの重複を避けるために、シリアル化されたエラーのハッシュコードを追加しました。もちろん、シリアル化されたメッセージをデータベースなどに保存できます。

Microsoft EnterpriseライブラリとLog4Netをチェックアウトすることをお勧めします。

Log4Netのいくつかの機能

• 複数のフレームワークのサポート
• 複数のロギングターゲットへの出力
• 階層ロギングアーキテクチャ
• XML設定
• 動的構成
• ロギングコンテキスト
• 実績のあるアーキテクチャ
• モジュール式で拡張可能な設計•高い柔軟性と柔軟性

データベースアプリケーションの場合<TABLE>:<PrimaryKeyID>、例外がキャッチされたスコープに関連するデータベース内のレコードを追跡できるようにする何らかのID（など）。

OracleとPL / SQLを使用して、例外ハンドラーからアプリケーション内のデータベーステーブルにIDを記録しました。

Amir Rezaeiが述べたように、あなたが説明するものの大部分（つまり、ロギングの特定の部分）はエンタープライズライブラリに実装されています。それ以外はすべて分析の部分（つまり、後でログをどうするか）のようです。

私の場合、いくつかのことを簡単にする小さなアプリとSQLスクリプトを作成しました。私が本当に気に入ったものをいくつか紹介します。

• 同じエラーをグループ化する（つまり、100人のユーザーがすべて同じ時間に同じバグを経験した場合は、発生した回数を記録した1つのバグレポート）
• ケーストラッカーでチケットを自動ファイリングします（これを「ボタンをクリックするだけ」にすることはできませんでしたが、常にしたかったのです）
• ソフトウェアのユーザーのユーザー名（ほとんどのロガーで使用可能なマシンだけでなく）。自動化されたユーザーアカウントが問題を引き起こした場合もあれば、特定のユーザーが問題の原因となった場合もあります。「マイクが何らかの仕事をするのを見る必要があります。彼は特定のエラーを引き起こし続けます。」
• 「ユーザーアクション」-ユーザーが行ったすべてのアクション可能なクリック/ボタンプレスのトレースを保持するグローバルスタックがあり、エラーログに記録しました。エラーを再現するには、多くの場合、そのトレースをたどって、ユーザーと同じ手順を実行します（トレースを解析して自動的に手順を実行するCodedUIテストジェネレーターを作成したかったのですが、実行しませんでした）

ログ情報が大きすぎてディスクに保存できない場合があります。私が見たアプローチの1つは、ログエントリをfirehose（perlなど）に次のように書き込むことです。

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

アナリストは、自分が見たいものを把握できます。

私たちのアプリケーションのエラー監視から学んだことは次のとおりです。

• ローリングログファイル（通常、アプリケーションへのログインにlog4net / log4jを使用し、ログを追跡するためにBareTailを使用）を追跡できることは、システムの現在の状態を確認できるために非常に便利です。
• 問題が発生した時期と問題の発生率を確認するには、レポートを実行できるタイムスタンプ付きのデータベースに問題があると便利です。
• 電子メール/ SMS /音声アラートを送信する機能は、システムが稼働していることを確認するのに非常に役立ちますが、アラートを発生させるエラーのタイプを簡単にカスタマイズできる必要があります。1日に800件のエラー電子メールを受信して​​いる場合、「データセンターが稼働していません」というメールを見逃すことになります。

log4netを使用すると、複数の場所に簡単にログを記録し、ロギング構成の変更も簡単に行えるため、素晴らしい結果が得られました。

elmahは、ASP.NETアプリ用のオープンソースエラーロギングシステムであり、既存のシステムに（NuGet http://nuget.codeplex.com/を使用して）迅速かつ簡単に追加できます。さまざまなバックエンドと通知機能をサポートしています。

デスクトップアプリはWebサイトとして実行されるため、デスクトップアプリに追加した人は誰も知りませんが、サービスとして実行し、Web経由で例外を投稿することを妨げるものは何もありません。

http://code.google.com/p/elmah/

ELMAH（エラーロギングモジュールとハンドラー）は、完全にプラグ可能なアプリケーション全体のエラーロギング機能です。実行中のASP.NET Webアプリケーション、またはマシン上のすべてのASP.NET Webアプリケーションに動的に追加でき、再コンパイルや再デプロイの必要はありません。

ELMAHが実行中のWebアプリケーションにドロップされ、適切に設定されると、コードを1行も変更せずに次の機能を取得できます。

• ほぼすべての未処理の例外のログ。
• 記録された例外のログ全体をリモートで表示するWebページ。
• 色付きのスタックトレースなど、ログに記録された例外の詳細をリモートで表示するWebページ。
• 多くの場合、モードがオフになっている場合でも、ASP.NETが特定の例外に対して生成した元の黄色の死の画面を確認できますcustomErrors。
• 発生時の各エラーの電子メール通知。
• ログからの最後の15エラーのRSSフィード...