（Windows）异常处理：事件日志或数据库？ [英] (Windows) Exception Handling: to Event Log or to Database?

问题描述

我已经在已经将异常处理实施到事件日志的商店中工作，并在数据库中的表中。

I've worked in shops where I've implemented Exception Handling into the event log, and into a table in the database.

每个都有其优点，根据我的经验，我可以强调一些：

Each have their merits, of which I can highlight a few based on my experience:

事件日志

• 行业标准位置例外（+）


• 易于记录（+）


• 可以在这里记录数据库连接问题（+）


• 可以在事件日志（+）之前构建报告和查看应用程序。


• 需要经常刷新，如果有报道（ - ）


• 不像SQL记录一样可扩展[在SQL中添加自定义字段（如方法名称）]（ - ）

• Industry standard location for exceptions (+)
• Ease of logging (+)
• Can log database connection problems here (+)
• Can build report and viewing apps on top of the event log (+)
• Needs to be flushed every so often, if alot is reported there (-)
• Not as extensible as SQL logging [add custom fields like method name in SQL] (-)

SQL /数据库

• 可以处理大量数据（+）


• 可以处理快速量插入异常（+）


• 在负载平衡环境（+）中出现异常的单个存储位置


• 非常可自定义（+）


• 稍微更容易填写d报告/通知SQL存储（+）


• 与存储典型异常的地方不同（ - ）

• Can handle large volumes of data (+)
• Can handle rapid volume inserts of exceptions (+)
• Single storage location for exception in load balanced environment (+)
• Very customizable (+)
• A little easier to build reporting/notification off of SQL storage (+)
• Different from where typical exceptions are stored (-)

我没有任何重大考虑因素？

Am I missing any major considerations?

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

I'm sure that a few of these points are debatable, but I'm curious what has worked best for other teams, and why you feel strongly about the choice.

推荐答案

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

You need to differentiate between logging and tracing. While the lines are a bit fuzzy, I tend to think of logging as "non developer stuff". Things like unhandled exceptions, corrupt files, etc. These are definitely not normal, and should be a very infrequent problem.

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

Tracing is what a developer is interested in. The stack traces, method parameters, that the web server returned an HTTP Status of 401.3, etc. These are really noisy, and can produce a lot of data in a short amount of time. Normally we have different levels of tracing, to cut back the noise.

对于登录客户端应用程序，我认为事件日志是要走的路（我必须仔细检查，但我认为ASP.NET健康监控可以写入事件日志）。普通用户有权写入事件日志，只要您有安装程序（由管理员安装）创建事件源。

For logging in a client app, I think that Event Logs are the way to go (I'd have to double check, but I think ASP.NET Health Monitoring can write to the Event Log as well). Normal users have permissions to write to the event log, as long as you have the Setup (which is installed by an admin anyway) create the event source.

Sql日志记录的优点，但是不适用于事件记录：

Most of your advantages for Sql logging, while true, aren't applicable to event logging:

• 可处理大量数据：
  < em你真的有大量未处理的异常或其他高级别的错误吗？


• 可以处理快速卷插入的异常：一个单一的未处理的异常应该带你应用程序下降 - 它固有的速率有限。非开发人员的其他有趣的事件应该同样地聚合。


• 非常可自定义：事件日志中的消息是非常自由的文本。如果您需要更多信息，只需指向文本或结构化XML或二进制文件日志


• 更容易构建SQL存储的报告/通知：报告内置的事件日志查看器，通知系统是固有的 - 由于应用程序崩溃 - 或与其他非常关键的通知混合 - 没有什么借口丢失事件日志消息。对于公司或其他联网应用程序，有一千个和1个不同的应用程序已经从事件日志中剔除错误...有可能您的系统管理员已经在使用。

• Can handle large volumes of data: Do you really have large volumes of unhandled exceptions or other high level failures?
• Can handle rapid volume inserts of exceptions: A single unhandled exception should bring your app down - it's inherently rate limited. Other interesting events to non developers should be similarly aggregated.
• Very customizable: The message in an Event Log is pretty much free text. If you need more info, just point to a text or structured XML or binary file log
• A little easier to build reporting/notification off of SQL storage: Reporting is built in with the Event Log Viewer, and notification systems are, either inherent - due to an application crash - or mixed in with other really critical notifications - there's little excuse for missing an Event Log message. For corporate or other networked apps, there's a thousand and 1 different apps that already cull from Event Logs for errors...chances are your sysadmin is already using one.

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

For tracing, of which the specific details of an exception or errors is a part of, I like flat files - they're easy to maintain, easy to grep, and can be imported into Sql for analysis if I like.

90％的时间，您不需要它们，它们设置为WARN或ERROR。但是，当您将它们设置为INFO或DEBUG时，您将生成一个吨数据。 RDBMS具有很多开销 - 用于性能（ACID，并发等），存储（事务日志，SCSI RAID-5驱动器等）以及管理（备份，服务器维护等）），所有这些都是不需要追踪日志。

90% of the time, you don't need them and they're set to WARN or ERROR. But, when you do set them to INFO or DEBUG, you'll generate a ton of data. An RDBMS has a lot of overhead - for performance (ACID, concurrency, etc.), storage (transaction logs, SCSI RAID-5 drives, etc.), and administration (backups, server maintenance, etc.) - all of which are unnecessary for trace logs.

这篇关于（Windows）异常处理：事件日志或数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！