Quando ignorar erros comuns e o programa se recupera de [fechado]

Eu tenho um programa que faz centenas de solicitações diárias de CURL, SMTP e outras solicitações. Menos de 1% do tempo, uma solicitação CURL ou SMTP falhará. O melhor que posso dizer é que a causa do problema é externa e não pode ser corrigida para ser 100% confiável. Meu programa sempre é capaz de se recuperar dele e nenhuma interação humana é necessária. Eu tenho um sistema para enviar um alerta de email quando algo falhar. A grande maioria do que recebo são essas falhas inofensivas de CURL e SMTP.

Não devo enviar um alerta por email para falhas comuns das quais o programa se recupera?

Depende da sua aplicação.

Os e-mails podem ser úteis para uma estatística, mas, se não, eu evitaria esse spam.
O que faço em casos semelhantes: envie um resumo uma vez por dia para ser informado sobre o desempenho do seu programa (e que ele ainda está em execução).

Eu enviaria apenas um email se a taxa de erro exceder um limite predefinido, o que indica que é necessária intervenção humana.

Nesta situação, eu pararia imediatamente de enviar os emails.

Os e-mails de erro devem agir como um sinal de que algo está errado e que é necessário tomar uma ação. Como você recebe muitos deles, eles agem como ruído estático e você facilmente perderá um e-mail de erro realmente importante que foi recebido por outro motivo.

No entanto, se você receber 5 desses e-mails a cada hora e receber um e-mail como a cada minuto seria algo anormal, precisará criar um mecanismo que envie algo quando os erros / hora ultrapassarem um determinado limite. Como o único email pode não significar mais muito, a quantidade deles em um determinado período (minuto / hora / dia) pode significar algo maior.

O email não é uma boa ferramenta para rastrear erros. Examine produtos como o New Relic ou o App Insights para registrar todos os seus erros (e outras informações), para que você possa relatar ou enviar alertas por e-mail quando certas condições forem atendidas (por exemplo, quando ele muda de 1% com falha para> 10% com falha) )

Com e-mails separados para cada erro, você acaba ignorando os e-mails e pode nem perceber o salto de 1% para 10%. Pior ainda, seu provedor de e-mail pode ver o grande volume de e-mails quase idênticos de um endereço e marcá-los como spam.

Nesse tipo de situação, tente criar um algoritmo para criar um log de eventos de erro e enviar uma vez por dia. Como disse pieter, também coloque um alerta para o número excessivo de erros. Essa será uma maneira sistemática de gerenciamento de aplicativos e solução de problemas.