一般的なエラーを無視して、プログラムが[クローズ]から回復する場合

毎日何百ものCURL要求、SMTP要求、およびその他の要求を行うプログラムがあります。1％未満の時間で、CURLまたはSMTP要求は失敗します。問題の原因は外部にあり、100％信頼できるように修正することはできません。私のプログラムはいつでもそれから回復することができ、そこから人間の相互作用は必要ありません。何かが失敗したときに電子メールアラートを送信するシステムを導入しています。私が受け取るものの大部分は、これらの無害なCURLおよびSMTPの失敗です。

プログラムが回復する一般的な障害について、電子メールアラートを送信しないでください。

アプリケーションによって異なります。

メールは統計に役立つかもしれませんが、そうでない場合は、このスパムを回避します。
私が同じような場合に行うこと：1日1回要約を送信して、プログラムのパフォーマンス（およびプログラムがまだ実行されていること）を通知します。

エラー率が、人間の介入が必要であることを示す事前設定の制限を超えた場合にのみ、メールを送信します。

この状況では、メールの送信をすぐに停止します。

エラーメールは、何かが間違っており、アクションを起こす必要があるという合図として機能します。それらの多くを取得するため、それらは静的ノイズとして機能し、別の理由で届いた本当に重要なエラーメールを簡単に見逃してしまいます。

ただし、これらの電子メールを1時間に5通受け取り、毎分などの電子メールを受け取ることが異常な場合は、エラー/時間が特定のしきい値を超えたときに何かを送信するメカニズムを構築する必要があります。1通の電子メールはもうあまり意味がない可能性があるため、一定期間（分/時間/日）内の電子メールの量は、もっと大きなものを意味する場合があります。

メールは、エラーを追跡するのに適したツールではありません。New RelicやApp Insightsなどの製品を調べてすべてのエラー（およびその他の情報）を記録し、特定の条件が満たされた場合（たとえば、1％失敗から> 10％失敗に変化した場合）にレポートしたり、電子メールアラートを送信したりできます。 ）。

エラーごとに個別のメールを送信すると、メールを無視してしまうだけで、1％から10％へのジャンプに気付かない場合もあります。さらに悪いことに、電子メールプロバイダーは、1つのアドレスから同一に近い大量の電子メールを受信し、それらをすべてスパムとしてマークする場合があります。

このタイプの状況では、エラーイベントのログを作成し、1日に1回送信するアルゴリズムを作成しようとします。ピーターが言ったように、エラーの数が超過した場合にも警告を出します。それがアプリの管理とトラブルシューティングの体系的な方法になります。