Web アプリケーションのログを最小限に抑える方法についてアドバイスはありますか?
現在、すべてのエラーをログに記録しています。そのため、すべてのリクエストでエラーが発生する状況 (たとえば、データベース接続の問題) がある場合、すべてのリクエストですべてのユーザーについてログに記録される可能性があります。ご想像のとおり、冗長なログ エラーを含む巨大なログ ファイルを蓄積し始めるには、あまりにも多くのユーザーがあまりにも多くのことを行う必要はありません。
N 分以内に同じエラーをログに記録しないように、ある種のフラグ メカニズムを作成することにしました。これは 2 つの理由で好きではありません。1) 他の問題の中で最も重大な問題を隠す可能性があり、2) エラーのカスケードが適切にログに記録されず、以前にログに記録されたエラーが省略され、最初の診断が失敗する可能性があります。
この問題を抱えたのは私が初めてではないと確信しています... Webアプリの冗長なログメッセージを減らす方法について誰かアドバイスはありますか?
コメントでの質問に答えるために、私の知る限り、このタイプの機能を含むすぐに使えるソリューションはありません。
考慮すべきもう 1 つのアイデア (この時点で、あなたは自分の回答を受け入れたことに気づきました) は、システム内の各エラー ログ ポイントに ID を割り当てることです。エラーがログに記録されると、エラー ID とエラーが記録された時刻の単純なハッシュ テーブルを保持できます。次に、ログを処理するときに、エラーがハッシュに既に存在し、それが 5 分以内 (または任意の時間) である場合は、ログを中止してタイムスタンプを更新するだけです。
ユーザーにエラー メッセージ リクエストを送信してもらうことで問題が解決するかどうかはわかりません。すべてのユーザーがメッセージを送信すると、エラー ログとまったく同じになり、受信トレイだけがあふれてしまうためです。ログファイル自体を監視します。
最後のエントリと、ログに記録しようとしているエラーを比較してみてください。これが同じタイプとソースの場合は、最後に文字列「(repeated n times)」を追加します。
ロガーがそのような文字列とエラーの一致を確認するたびに、別のタイプのエラーが発生するまで n を増やすことができます。
これをユーザー エラー メッセージと組み合わせたので、エラー メッセージがユーザーに表示されたら、ユーザーは [OK] または [サポートに送信] をクリックできます。次に、完全なエラー、コール スタック、および完全な要求情報がバグ トラッカーに入力されます。
これはまだリリースされていないため、これが良いアイデアかどうかはまだわかりません... 引き続きお知らせします.
PS-記録として自分の質問に回答しましたが、他の回答が私のニーズを満たしていなかったため、それを選択しました。