.net - 如何阻止异常警报发狂

Question

假设您有一个 .NET 系统，当出现错误时需要向系统管理员发送电子邮件通知。例子:

try
{
    //do something mission critical 
}
catch(Exception ex)
{
    //send ex to the system administrator
    //give the customer a user-friendly explanation
} 

这个代码块每秒被不同的用户调用数百次。

现在假设底层 API/服务/数据库出现故障。这段代码会失败很多很多次。可怜的管理员会在他们的收件箱中醒来，发现几百万封电子邮件，而开发人员会接到一个粗鲁的电话，并不是说今天早上一定会发生这样的事件(咳嗽)。

很明显，这不是一个可以很好扩展的设计。

想到的前几个解决方案在某种程度上都有缺陷:

将错误记录到数据库，然后通过 HTTP 健康检查将高错误计数暴露给外部监控服务，例如 Pingdom . (到目前为止我最喜欢的候选人。但是如果数据库出现故障怎么办？)

有一个静态缓存来跟踪最近的异常，并且警报系统总是首先检查重复项。 (看起来不必要的复杂，其次，很多错误消息的差异非常小——例如，如果错误中有时间戳，它就没有用了。)

在某些错误后或基于对关键依赖项的持续监控以编程方式使我们的系统脱机(风险!如果出现短暂的误报怎么办？)

只是不对这些错误发出警报，而是依靠系统的不同部分来监视和报告依赖关系。 (不应对我们没有预料到的“意外”错误。)

这似乎是一个必须解决的问题，而我们正在以一种愚蠢的方式解决它。建议表示赞赏，即使它们涉及完全不同的异常管理策略!

Answer 1

想到的最简单的解决方案是为这个异常 block 分配一个 ID 号(如 1)，并将最后一次通知给管理员的时间记录下来。如果通知之间耗时不够长(例如一个小时)，请不要再次通知管理员

如果这段代码通常会产生不止一种异常，您可能还需要记录异常的类；如果同一异常的通知之间耗时不够大，请不要再次通知管理员