sql - (Windows) 异常处理 : to Event Log or to Database?

Question

我曾在商店工作过，我在事件日志和数据库的表中实现了异常处理。

每个人都有自己的优点，我可以根据我的经验强调其中一些:

事件日志

• 异常(exception)情况的行业标准位置 (+)
• 易于记录 (+)
• 可以在此处记录数据库连接问题 (+)
• 可以在事件日志之上构建报告和查看应用程序 (+)
• 需要经常冲洗，如果那里报告了很多 (-)
• 不像 SQL 日志记录那样可扩展[在 SQL 中添加自定义字段，例如方法名称] (-)

SQL/数据库

• 可以处理大量数据 (+)
• 可以处理异常的快速卷插入 (+)
• 负载平衡环境中的异常的单一存储位置 (+)
• 高度可定制 (+)
• 通过 SQL 存储构建报告/通知变得更容易 (+)
• 与典型异常的存储位置不同 (-)

我是否遗漏了任何主要考虑因素？

我确信其中一些观点是有争议的，但我很好奇什么对其他团队最有效，以及为什么您对这个选择有强烈的感觉。

Answer 1

您需要区分日志记录和跟踪。虽然界限有点模糊，但我倾向于将日志记录视为“非开发人员的东西”。诸如未处理的异常、损坏的文件等。这些绝对不正常，并且应该是一个非常罕见的问题。

跟踪是开发人员感兴趣的。堆栈跟踪、方法参数、Web 服务器返回的 HTTP 状态 401.3 等。这些确实很嘈杂，并且可以在短时间内产生大量数据。通常我们有不同级别的跟踪，以减少噪音。

对于登录客户端应用程序，我认为事件日志是最佳选择(我必须仔细检查，但我认为 ASP.NET 运行状况监控也可以写入事件日志)。普通用户有权写入事件日志，只要您让安装程序(无论如何都是由管理员安装的)创建事件源。

Sql 日志记录的大部分优势虽然确实存在，但不适用于事件日志记录:

• 可以处理大量数据:您是否真的有大量未处理的异常或其他高级故障？
• 可以处理异常的快速批量插入:单个未处理的异常应该会导致您的应用程序崩溃 - 它本质上是速率有限的。非开发人员感兴趣的其他事件也应以类似方式聚合。
• 非常可定制:事件日志中的消息几乎是自由文本。如果您需要更多信息，只需指向文本或结构化 XML 或二进制文件日志
• 从 SQL 存储构建报告/通知更容易一些:报告是通过事件日志查看器内置的，通知系统要么是固有的(由于应用程序崩溃)，要么与其他真正关键的内容混合在一起通知 - 没有理由错过事件日志消息。对于企业或其他网络应用程序，已经有一千零 1 个不同的应用程序已从事件日志中剔除错误...很可能您的系统管理员已经在使用其中一个。

对于跟踪，异常或错误的具体细节是其中的一部分，我喜欢平面文件 - 它们易于维护，易于 grep，并且可以导入到 Sql 中如果我愿意的话可以进行分析。

90% 的情况下，您不需要它们，并且它们被设置为“警告”或“错误”。但是，当您将它们设置为 INFO 或 DEBUG 时，您将生成大量数据。 RDBMS 具有大量开销 - 性能(ACID、并发性等)、存储(事务日志、SCSI RAID-5 驱动器等)和管理(备份、服务器维护等) - 所有这些都是跟踪日志不需要。