Como devo lidar com falhas do criador de logs?

Em várias aplicações da nossa empresa, usamos um criador de logs personalizado. É bastante robusto, embora possamos substituí-lo por algo como NLog no futuro. Uma das tarefas do criador de logs é registrar quaisquer exceções encontradas no aplicativo.

Uma preocupação que sempre tive é que o tratamento de exceções no criador de logs permite uma falha silenciosa. Ou seja, se o log não for gravado para uma determinada exceção (devido a um erro no criador de logs), como devo lidar com isso e (de alguma forma) registrar a exceção no próprio criador de logs ?

Digamos que a função WriteLog lança uma exceção. Devo tentar chamar a função várias vezes ou até que a exceção não seja lançada? Devo tentar escrever a exceção lançada com o criador de logs (o que provavelmente resultaria em exceções até o fim ...)? Tive a sorte de não encontrar essa situação, exceto quando estávamos implementando o criador de logs personalizado. Por outro lado, não tenho como saber no momento se o criador de logs falhou ao registrar exceções de aplicativos (devido a suas próprias exceções).

Eu tentei pesquisar on-line e em alguns sites SE, mas até agora tem sido infrutífero, pois todas as postagens lidam com erros em um criador de logs (mas não com possíveis exceções e como registrá-los) ou com exceções fora do criador de logs.

Ao encontrar exceções no próprio criador de logs, você não deve usá-lo para registrar suas próprias exceções. A razão para isso é que:

• Você pode ficar preso em um loop infinito. Imagine que, no seu criador de logs, você tenha uma ramificação condicional que não foi testada (e gera uma exceção). Imagine que, uma vez que a condição seja atendida, qualquer outra exceção relatada seja tratada pelo mesmo ramo. Isso significa que, a partir do momento em que o ramo é executado, você está em um loop infinito.

• Você pode ficar preso em um loop temporário, gerando milhares de exceções por segundo. Imagine que você está relatando exceções para um servidor remoto. Um problema no servidor causa outra exceção, que causa outra, e assim por diante, até que a conexão volte.

O que você deve fazer é recorrer a uma maneira mais segura de registrar as exceções. Por exemplo, se o seu criador de logs envia as exceções para um servidor remoto, envie as exceções dentro do criador de logs para syslog. Se o seu criador de logs registrar exceções nos Eventos do Windows e essa ação falhar, armazene a exceção de falha em um arquivo de texto simples.

Depois disso, a próxima pergunta é como você sabe que essas exceções ocorreram: se você tem dezenas de aplicativos em execução em milhares de servidores, não é possível fazer o SSH de cada um deles regularmente para verificar se eles estavam registrando algo localmente .

Uma maneira é ter um trabalho cron que verifique esses “logs excepcionais” e os empurre para o local onde outras exceções estão armazenadas (eventualmente usando o seu logger, mas tenha cuidado com loops infinitos ou temporários!).

Se o registro for crítico para o seu aplicativo, deve-se parar o aplicativo se o registro falhar.

Se não for crítico, sendo um pouco defensivo, pode haver um componente secundário para lidar com falhas de log que registra / alerta para uma fonte secundária. Mas mesmo isso não é à prova de idiotas e você terá que considerar o que acontece se o criador de logs secundário falhar enquanto estiver monitorando o criador de logs primário.

Uma boa estratégia é registrar em um arquivo local e, se isso falhar, talvez registrar essa falha no log de eventos, gerar um alerta por email, salvar em um banco de dados etc. Com as estruturas de log disponíveis, isso deve ser infalível, a menos que a máquina seja executada falta de espaço em disco ou alguma outra condição rara.

Idealmente, é melhor falhar silenciosamente, pois isso tornará o aplicativo menos complexo.

Mais importante, para lidar com falhas de log, deve-se monitorar os logs de terceiros. Com o tempo, você poderá discernir quantos eventos um aplicativo saudável está registrando. Se ele começar a registrar eventos baixos ou inexistentes, através do monitoramento, você poderá ver o problema ocorrendo e potencialmente alertar através desse mecanismo de terceiros.