ASP.NET 日志记录 - log4net 或运行状况监控？
我正在查看 3.5 中的一个新的 asp.net 站点，它完全没有错误处理或日志记录。 记录和处理错误有哪些好的选择？ 我在 1.1 框架上使用了 Log4Net，但听说 3.5 中可能有更好的选择。
I'm looking at a fresh asp.net site in 3.5 that has absolutely no error handling or logging. What are some good options for logging and handling errors? I've used Log4Net on the 1.1 framework but hear there are potentially better options in 3.5.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一种选择是 ELMAH。 我在这里提出了一个相关问题：ASP.NET 错误处理。
从那时起，我实现了它的一个稍微修改的版本，日志记录和电子邮件非常棒，并且可以通过 web.config 文件轻松集成。
One option is ELMAH. I asked a question about it here: ASP.NET Error Handling.
Since then, I have implemented a slightly modified version of it and the logging plus e-mail is great and easy to integrate via the web.config file.
我们使用两个选项进行日志记录：-
ELMAH 用于意外异常处理
NLog 获取预期的手动（调试、信息和错误）信息。
ELMAH 是一个很棒的开箱即用插件，可以自动捕获异常（从 404（未找到页面）到抛出的 500 个异常），并具有内置的 Web-ui 来可视化这些错误。 因此，这是一种非常快速有效的方法来捕获发生的意外错误。
现在，NLog 通过让我们的开发人员在特定位置手动将调试信息插入到代码中来对此表示赞赏，因此当我们需要从非本地主机系统中获取信息时，这是非常方便的简单的。 例如，我们在大多数方法中添加
log.Debug(..)代码来查看局部变量是什么或返回值等。对于更重要的信息，我们使用log .Info(..)..但是使用这个的次数要少得多。 最后，对于我们捕获和处理的严重错误，我们使用log.Error(..)或log.Warn(..).. 通常在某些try/catch范围。 因此，在我们的测试或实时服务器上，如果我们需要获取大量数据、实时数据……或者只是一般的重要信息，那么我们会打开所有日志记录状态（例如调试及更高级别）正如Info所声明的那样以及更高的内容。Warn、Error 和 Fatal状态始终处于开启状态。 调试状态会生成大量数据，因此我们很少使用它们。总而言之，我建议您对 Web 应用程序使用两种方法。 Elmah 提供出色的意外错误捕获，NLog 提供预期信息和错误。
最后，NLog 比 Log4Net 更容易使用/工作。 IMO，它基本上取代了它。
We use two options for our logging:-
ELMAH for unexpected exception handling
NLog for expected, manual (debug, info and error) information.
ELMAH is a great out-of-the-box plugin that automatically captures exceptions (from 404's (page not found) to 500 exception thrown) and has a built in web-ui to visualize these errors. So it's a really quick and effective way of grabbing unexpected errors that occur.
Now NLog compliments this by having our developers manually insert debugging information into the code at specific spots, so when we need to get information out of a non-locahost system, it's very easy. For example, we litter
log.Debug(..)code in most of our methods to see what the local variables are or returned values, etc. For more important information, we then uselog.Info(..).. but use this a lot less. Finally, for serious errors which we have trapped and handle, we uselog.Error(..)orlog.Warn(..).. generally inside sometry/catchscopes. So on our test or live servers, we then turn on all logging states (eg.Debugand greater) if we need to grab LOTS of data, live... or just the general important information, such asInfostates and greater. We always haveWarn, Error and Fatalstates always on. Debug state generates a LOT of data, so we use that only sparingly.So to summarize, I suggest you use TWO approaches to your WebApp. Elmah for excellent unexpected error trapping and NLog for expected information and errors.
Finally, NLog is WAAAY easier to use/get working than Log4Net. It basically superceeds it, IMO.
如果您习惯了 log4net，请坚持您所知道的。 它简单、快速且效果良好。 我已经在 1.1、2.0 和现在的 3.5 中使用它多年了。
If you are used to log4net, stick with what you know. It's easy, fast, and works well. I've used it for years in 1.1, 2.0, and now 3.5.
ASP.NET 健康监控实际上开箱即用，做得相当不错！
MSDN，如何：发送电子邮件以获取运行状况监控通知
ASP.NET Health Monitoring actually does a pretty decent job right out of the box!
MSDN, How to: Send E-mail for Health Monitoring Notifications
企业库可能有一个学习曲线，但它是一个很好的项目。
在 Asp.Net 中，遵循 david hayden 的文章 Enterprise Library 2.0 日志记录应用程序块
Enterprise Library maybe has a learning curve but is a good project.
In Asp.Net follow david hayden's article Enterprise Library 2.0 Logging Application Block
就我个人而言，我还没有尝试过 log4net，但看过 winforms 的规范和示例，但我的组织编写了我们自己的日志记录机制，该机制报告和记录在 global.asax 中捕获的错误，该错误报告我们需要了解的有关堆栈跟踪、会话的所有信息（如果存在）、表单的 NVC、应用程序的版本、引发带有查询字符串的错误的 URL 以及 HTTP 标头。 尽管我注意到并非所有错误都会记录在那里； 例如表单身份验证到期或应用程序池重新启动/关闭或 IIS 报告但应用程序执行时未抛出的任何内容。
Personally, I havent tried log4net but seen the specs and examples for winforms, but my organization coded our own logging mechanism that reports and logs errors that are caught in the global.asax that reports everything we need to know about the stack trace, session (if exists), form's NVC, version of the app, URL that originated the error with querystring, and HTTP headers. Though I noticed that not all errors get logged there; such as forms authentication expiration or application pool restart/shutdown or anything reported by IIS that was not thrown by the application executing.