假设您有一个 .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。(到目前为止我最喜欢的候选人。但是如果数据库出现故障怎么办?)
- 有一个静态缓存来跟踪最近的异常,并且警报系统总是首先检查重复项。(似乎不必要的复杂,其次,许多错误消息略有不同 - 例如,如果错误中有时间戳,它是无用的。)
- 在某些错误后或基于对关键依赖项的持续监控以编程方式使我们的系统脱机(风险!如果有短暂的误报怎么办?)
- 只是不对这些错误发出警报,而是依靠系统的不同部分来监视和报告依赖关系。(不满足我们没有预料到的“意外”错误。)
这似乎是一个必须解决的问题,而我们正在以一种愚蠢的方式解决它。建议表示赞赏,即使它们涉及完全不同的异常管理策略!