一般的なエラーを無視してプログラムを回復する場合
毎日何百ものCURLリクエスト、SMTPリクエスト、その他のリクエストを作成するプログラムがあります。 1％未満の時間で、CURLまたはSMTP要求は失敗します。問題の原因は外部にあり、100％信頼できるように修正することはできません。私のプログラムはいつでもそれから回復することができ、そこから人間の相互作用は必要ありません。何かが失敗したときに電子メールアラートを送信するシステムを導入しています。私が受け取るものの大部分は、これらの無害なCURLおよびSMTPの失敗です。
プログラムが回復する一般的な障害についてメールアラートを送信すべきではありませんか？
アプリケーションによって異なります。
メールは統計に役立つかもしれませんが、そうでない場合は、このスパムを回避します。
同様の場合の対処方法：1日1回要約を送信して、プログラムのパフォーマンス（およびプログラムがまだ実行されていること）を通知します。
エラー率が、人間の介入が必要であることを示す事前設定の制限を超えた場合にのみ、メールを送信します。
この状況では、メールの送信をすぐに停止します。
エラーメールは、何かが間違っていることを示すシグナルとして機能し、アクションを実行する必要があります。それらの多くを取得するため、それらは静的ノイズとして機能し、別の理由で届いた本当に重要なエラーメールを簡単に見逃してしまいます。
ただし、これらの電子メールを1時間に5通受信し、毎分などの電子メールを受信するのが異常な場合は、エラー/時間が特定のしきい値を超えたときに何かを送信するメカニズムを構築する必要があります。 1通のメールで意味がなくなったため、一定期間（分/時/日）のメールの量が大きくなっている可能性があります。
メールは、エラーを追跡するのに適したツールではありません。 New RelicやApp Insightsなどの製品を調べてすべてのエラー（およびその他の情報）を記録し、特定の条件が満たされた場合（たとえば、1％失敗から> 10％失敗に変化した場合）にレポートしたり、電子メールアラートを送信したりできます。 ）。
エラーごとに個別のメールを送信すると、メールを無視してしまい、1％から10％へのジャンプに気付かない場合があります。さらに悪いことに、あなたのメールプロバイダーは、1つのアドレスからの同一に近い大量のメールを見て、それらをすべてスパムとしてマークするかもしれません。
このタイプの状況では、エラーイベントのログを作成し、1日に1回送信するアルゴリズムを作成しようとします。ピーターが言ったように、エラーの数の超過についても警告を出します。それがアプリの管理とトラブルシューティングの体系的な方法になります。