如何停止异常警报

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）公开大量错误。 （到目前为止，我最喜欢的候选人。但是，如果数据库崩溃了怎么办？）
• 具有静态缓存，可跟踪最近的异常，并且警报系统始终会首先检查重复项。 （似乎不必要地复杂，其次，许多错误消息之间的差别很小-例如，如果错误中带有时间戳，则它是无用的。）
• 在出现某些错误后或基于对关键依赖项的持续监视，以编程方式使我们的系统脱机（Risky！如果出现暂时的误报，该怎么办？）
• 只是不对那些错误发出警报，而是依靠系统的不同部分来监视和报告依赖性。 （不满足我们未曾预料到的“意外”错误。）

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

Answer 1

我想到的最简单的解决方案是为该异常块分配一个ID号（例如1），并将最后一次通知的时间记录给管理员。 如果两次通知之间经过的时间不够长（例如一个小时），请不要再次通知管理员

如果这段代码通常生成不止一种异常，则您可能还希望记录该异常的类； 如果相同异常的两次通知之间经过的时间不够长，请不要再次通知管理员

Answer 2

检查相似性（可以使用通配符（例如，??：??逃避时间戳）），然后先将它们发送给您一段时间。 现在检查发生最多的事件。

假设有1000个A型例外，964个B型例外，120个C型例外和7个D-H型例外。

这意味着，每隔100个A型和B型异常，每10个C型异常以及其他所有异常都向sysadmin发送电子邮件。

优点：
+准确
+防止系统垃圾邮件
+没有多少代码要实现

缺点：
-需要时间来制定可靠的统计数据
-重要异常可以意外忽略
-依靠人类，这可能总是失败

Answer 3

我曾经构建过监视应用程序，可以通过电子邮件向管理员发送电子邮件，但我会令人毛骨悚然地承认我遇到了您的情况。 解决方案是对电子邮件进行速率限制。 保存上次发送电子邮件的时间，并进行检查以查看自上一封电子邮件以来是否经过了最短的时间，然后再发送一次（取决于您，是10分钟或更长时间）。 这样，可怜的管理员可以收到的最大电子邮件数量将是<time issue has been going on> / <period> 。 在我之前的sysadmin工作中，这平衡了我们的需要，即知道问题仍然存在，并且需要一个电子邮件箱每小时不发送1000封电子邮件。

Answer 4

我们的一个远程应用程序中有类似的内容。 它会通过电子邮件向中介邮箱发送所有例外情况，并且脚本会每小时运行一次，以扫描邮件，并创建摘要电子邮件，然后发送到我们的团队邮箱（每天最多24封邮件），并将其余数据保存到本地数据库，以供将来参考。

它不是防弹的，但安装起来相当快捷/容易。

Answer 5

我知道这个问题已经得到解答，但是我仍然认为发布此问题很有帮助。

微软一直在添加有关云设计模式和体系结构的大量信息，从诸如微服务和带有消息队列的服务总线之类的信息，到细微的细节。 全部都在Microsoft Docs网站上，该网站在Azure Architecture下提交。 处理此类问题的特定模式是断路器模式 。

使用此模式不能完全解决问题。 仍然存在“我们如何确定是时候通知操作人员了吗？”的问题。 一种可能的解决方案是让断路器跳闸，并增加一个内部计数器以创建跳闸的唯一标识符（或类似的东西）。 然后，后续通知可以使用此标识符。 这只是一个例子-可能还有其他方式可以合理地完成此操作。 关键是，我将使用断路器来处理决策逻辑，方法是将断路器放置在需要它的服务所在的任何位置，然后将其链接到其上以提供您要描述的有关通知的服务。 但是，至少，您可以避免发送大量电子邮件。