我应该如何处理记录器故障？

在公司的一些应用程序中，我们使用自定义记录器。它相当健壮，尽管将来我们可能会用NLog之类的东西来代替它。记录器的任务之一是记录应用程序中遇到的任何异常。

我一直担心的一个问题是，记录器中的异常处理允许出现静默故障。也就是说，如果未针对给定的异常编写日志（由于记录器中的错误），那么我应该如何处理该异常并（以某种方式）将异常记录到记录器本身中？

假设WriteLog函数引发异常。我应该尝试多次调用该函数还是直到不引发异常之前？我是否应该尝试使用记录器编写引发的异常（这很可能会导致异常完全消失……）？除了第一次实现自定义记录器时，我很幸运没有遇到这种情况。另一方面，我目前无法知道记录器是否未能记录应用程序异常（由于其自身的异常）。

我已经尝试过在线和在一些SE网站上进行搜索，但是到目前为止，由于所有帖子都处理记录器中的错误（但不记录潜在的异常以及如何记录它们）或记录器外部的异常，到目前为止，这种方法是徒劳的。

当记录器本身遇到异常时，您不应使用记录器记录其自身的异常。原因是：

• 您可能会陷入无限循环。想象一下，在您的记录器中，您有一个未经测试的条件分支（并生成异常）。想象一下，一旦满足条件，任何进一步报告的异常都将由同一分支处理。这意味着从执行分支的那一刻起，您就处于无限循环中。

• 您可能会陷入一个临时循环中，每秒生成数千个异常。想象一下，您正在向远程服务器报告异常。服务器出现问题会导致另一个异常，导致另一个异常，依此类推，直到连接恢复。

相反，您应该做的是退回到更安全的方式来记录异常。例如，如果您的记录器将异常发送到远程服务器，则将记录器内的异常发送到syslog。如果您的记录器在Windows事件中记录了异常并且此操作失败，则将失败异常存储在简单的文本文件中。

有了这些之后，接下来的问题是如何知道这些异常发生了：如果您有成千上万的服务器上运行着数十个应用程序，则可能无法定期对每个应用程序进行SSH来检查它们是否在本地进行日志记录。

一种方法是进行cron作业，以检查那些“异常日志”并将其推送到存储其他异常的位置（最终使用记录器，但要注意无限循环或临时循环！）。

如果日志记录对您的应用程序至关重要，那么如果日志记录失败，则应停止应用程序。

如果不是很关键，则可以采取防御措施，它可以具有一个辅助组件来处理记录/警报到辅助源的日志记录失败。但这还不是万无一失的，您将不得不考虑如果辅助记录器在监视主记录器时发生故障会发生什么。

一个好的策略是将日志记录到本地文件，如果失败，则可能将该故障记录到事件日志，生成电子邮件警报，保存到数据库等。使用可用的日志记录框架，这应该是万无一失的，除非计算机可以运行磁盘空间不足或其他一些罕见情况。

理想情况下，您最好静默地失败，因为这会使应用程序更简单。

更重要的是，要处理日志记录失败，应该监视第三者的日志。随着时间的流逝，您应该能够分辨出运行状况良好的应用程序正在记录多少事件。如果它开始记录低事件或无事件，那么通过监视您可以看到问题的发生，并可能通过该第三方机制发出警报。