2

現在のWeb開発プロジェクトでは、エラーにフラグを付け、発生した内容の詳細を記載した電子メールを管理者に自動的に送信するバックエンドシステムを実装しています。エラーをトラップし、適切なエラー情報を含む電子メールを生成するのは非常に簡単です。ただし、特にサイトに頻繁にアクセスしている場合に、エラータイプの特定のグループを考慮すると、問題が発生します。

いくつかの例を考えてみましょう。

  1. Webサーバー上のすべてのスクリプトが接続できなくなる計画外のデータベース停止。データベースサーバーがオンラインに戻るのに2分（120秒）かかり、Webサーバーが10 /秒の速度で一意の要求を受信して​​いる場合、データベースサーバーがオンラインに戻るのにかかる時間内に管理者の電子メールデータベースへの接続の失敗について叫ぶ1200通の同一の電子メールが殺到するでしょう。
  2. スクリプトのバグは、テストによってなんとかこっそりと実行され、コンテンツの生成を完全に台無しにし、特定の状況でのみ発生するさまざまなものです（たとえば、100リクエストごとに1回）。一意のリクエストレートである10/秒を再度使用すると、管理者は、修正されるまで、同じバグについて10秒ごとに同じメールを受信することになります。

このシナリオの発生を防ぐために使用できるアプローチ/戦略は何ですか？（スクリプトによって生成されたエラーの監視にのみ関心があります。インフラストラクチャの問題はこのソリューションの範囲を超えています）

set_error_handlerによって設定されたエラーハンドラコールバックに渡された値の一部のダイジェストを使用して、ほとんどの場合、エラーを一意に識別できると想定します。

最初の、そしておそらく最も明白な解決策は、データベースに記録し、最後に発生してから妥当な最小期間が経過した場合にのみ電子メールを送信することです。これは、特にデータベースが問題を引き起こしている場合、理想的なアプローチではありません。別の解決策は、エラーが発生したときにファイルをディスクに書き込み、ファイルが最後に変更されてから妥当な最小期間が経過したかどうかを確認することです。私が説明した2つの方法以外に、この問題を解決するメカニズムはありますか？

4

4 に答える 4

2

単にそれらすべてを送信してから、受信者側のデータベースに収集して保存することを許可してはどうでしょうか。そうすれば、データベースがサーバーの問題になる可能性を回避できます。

また、私の意見では、貴重なフォレンジックデータを勝手に捨てないという大きな利点があります。事後分析は非常に重要であり、あらゆる種類のフィルタリングにより、非常に困難または不可能になる可能性があります。

于 2009-02-11T03:00:41.287 に答える
1

SiteScopeのような監視ソフトウェアを調べてみましたか？

于 2009-02-11T02:59:02.490 に答える
1

私がしたことは、エラー ログを監視し、5 分ごとにダイジェストを送信することでした。私の高品質のコードのせいだと思いたいのですが (人気のないアプリに対して!)、あまり面倒なことはしません:PI は基本的にログ ファイルを最初から最後まで読み、エラー メッセージを解析し、タイムスタンプ < ジョブを最後に実行した時刻、次に簡単なメールを送信します。

これは十分に機能します。ただし、POST を多用すると、Apache のアクセス ログと php のエラー ログを関連付けて得られる情報は限られます。Apache内からPOSTをファイルに記録するモジュールについて読んだことは覚えていますが、詳細は覚えていません。

ただし、エラー ハンドラーを使用してどこかに書き込みたい場合は、より多くの情報にアクセスできるので、それが最適です。ip、セッションID（およびページネーションなどの設定に影響を与える可能性のあるユーザー情報）、関数引数（debug_backtraceなど）...すべてのエラーを書き込み、新しいエラーが発生したとき、またはエラーの後にメッセージを送信するだけです認められています（そのようなシステムを書きたい場合）。

于 2009-02-11T04:17:16.860 に答える
0

先に進んで、必要なログ ファイルを生成する必要があります。ただし、メールを自分で送信する代わりに、ログをNagiosなどの監視システムに接続します。管理者にアラートを出すタイミングと頻度は、監視ソリューションに任せます。

于 2009-02-11T15:35:35.713 に答える