(Windows)异常处理:事件日志或数据库？

Question

我曾在我已经在事件日志中实现异常处理的商店中工作,并在数据库中的表中工作.

每个都有它们的优点,我可以根据我的经验强调一些:

事件簿

• 异常的行业标准位置(+)
• 易于记录(+)
• 可以在这里记录数据库连接问题(+)
• 可以在事件日志(+)之上构建报告和查看应用程序
• 需要经常刷新,如果有很多报道( - )
• 不像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 驱动器等）和管理（备份、服务器维护等） - 所有这些都是跟踪日志不需要。