【问题标题】:C# Logging. What should I use? [closed]C# 日志记录。我应该使用什么? [关闭]
【发布时间】:2011-06-07 22:36:06
【问题描述】:

我正在考虑切换到新的统一日志记录解决方案以用于我们的新产品线,我想看看 Stack Overflow 上的一些人是怎么想的。我们需要记录各种应用程序:ASP .net、Windows 服务、Web 服务、wpf 应用程序等。我们只是一家 Windows 商店。

我们对日志记录解决方案的一些要求包括:

1) 日志文件管理

- Ability to split files up over a certain size
- Ability to auto archive/delete after certain period of time

2) 能够针对记录的某些类型的消息(例如错误)发送电子邮件

3) 能够将消息写入 Windows 事件日志

- We need to be able to specify where it's being written in the event log. 
  It would also be nice if it would automatically create the event log source if it does exist.

我已经开始研究 nLog、windows trace 和 log4net。我不限于这三个,只是搜索时出现了很多。

【问题讨论】:

  • log4net 是迄今为止最常用的一种,并且支持所有这些要求。这是我会使用的,但 YMMV。
  • 试试这个:stackoverflow.com/search?q=[.net]+logging 你会发现很多有趣的答案。
  • 重复,但Cole W确实提出了他想到的一些具体要求,这对这个问题很好。

标签: c# windows logging


【解决方案1】:

log4net 总是一个不错的选择。

http://logging.apache.org/log4net/

【讨论】:

  • 不,如果您想要一些易于实现的东西,这不是一个好的选择。当然,如果您已经是 log4net 用户,那么这对您来说可能很容易。对于以前从未使用过它的人来说,设置它是一件很痛苦的事情。
  • 比编写自己的日志框架更痛苦!
  • @Pedro 你在实现什么?您可以找到有关如何设置记录器的 app.config 示例。
  • 如果您愿意 RTFM,Log4 很容易“实施”。
  • @Pedro 你有其他建议吗?
【解决方案2】:

使用 .NET common logging。您可以稍后选择特定的提供程序(NLog、CLog、log4net...),甚至创建自定义提供程序。

【讨论】:

  • 但是如果我想避免对 .NET 通用日志的依赖怎么办?老实说,这对我来说似乎是不必要的抽象层。 log4net 等人本身就是对日志记录的抽象——我有什么可能的理由想要将一个交换另一个而不是反对使用 .NET 通用日志记录?
  • 这类似于 Java 的 apache commons logging,同样的论点适用于它的存在。假设您正在编写将在其他代码中使用的库。您不想规定在与您的库交互的任何代码中使用哪个日志框架,因为这意味着客户端必须为您的特定框架进行配置。假设您决定使用 log4net,另一个库使用 NLog,那么客户端必须同时存在这两个配置才能使用这两个库。 Commons 允许您从客户端代码继承日志框架。
【解决方案3】:

还有一个:NLog。

  • 文件 – 单个文件或多个文件,带有 自动文件命名和归档
  • 事件日志 – 本地或远程数据库 – 将您的日志存储在支持的数据库中
  • 通过 .NET 网络 – 使用 TCP、UDP、 SOAP、MSMQ 协议
  • 命令行控制台 - 包括颜色编码 消息
  • 电子邮件 – 您可以接收 每当应用程序错误时发送电子邮件 发生
  • ASP.NET 跟踪
  • 还有更多

【讨论】:

  • 我在之前的项目中使用了 NLog,发现它确实比 Log4Net 更容易配置(无法正常工作,莫名其妙)。
【解决方案4】:

您可以查看 Enterprise Library,它们有一个可扩展的日志记录应用程序块

http://entlib.codeplex.com/

http://entlib.codeplex.com/releases/view/46741

您可以下载开发指南 pdf,他们有一个关于日志记录的部分(第 4 章)

【讨论】:

  • 我们对那个文件有非常糟糕的体验 - 在 Web 服务器上,它记录并锁定了文件(也就是说,它没有及时释放它以获取另一个日志) ,因此下一个日志转到以 GUID 作为名称的其他文件...对于任何生产环境都非常不切实际...
  • 听起来您正试图从多个进程登录到同一个文件(或使用多个指向同一个文件的TraceListeners)。请参阅:stackoverflow.com/questions/1728571/…。自从 Enterprise Library 发布以来,我一直在企业生产环境中使用它,我有非常好的经验。
【解决方案5】:

请参阅此问题以获得另一个全面的答案:When should I use Tracing vs Logger.NET, Enterprise Library, log4net or Ukadc.Diagnostics?

简而言之,可用的主要日志框架是内置的 .NET Framework System.Diagnostics、log4net、NLog 和 Enterprise Library Logging Application Block。

这些主要框架的比较可在:https://essentialdiagnostics.codeplex.com/wikipage?title=Comparison

1) 日志文件管理

上面列出的所有主要框架都支持滚动文件,但我认为它们会将清理工作留给您。

例如过去,我使用了一个计划的 Windows 作业,该作业使用带有“/mov /minage X”的 robocopy 将旧文件移动到其他地方,然后删除或其他。

System.Diagnostics 中使用的 EventSchemaTraceListener,我 blogged about recently,有一个 LimitedCircularFiles 选项,但没有太多工具支持查看日志(它们是 XML 格式)。

2) 能够针对记录的某些类型的消息(例如错误)发送电子邮件

上面列出的所有主要框架都直接或通过扩展(附加侦听器)支持这一点。

3) 能够将消息写入 Windows 事件日志

同样,所有主要框架都支持这一点,但我通常建议直接写入 Windows 事件日志,而不是通过跟踪。

其中一个问题是您询问了关于自动创建源的问题。

对事件日志的任何写入(通过 EventLog.WriteEvent) 如果第一条日志消息不存在,则会自动尝试创建源 - 问题在于安全性,只允许管理员创建源,因此以普通用户身份运行会失败。

因此,您确实需要添加一个 EventLogInstaller,以便在安装时创建源(安装由管理员完成)。创建后,任何进程都可以写入源。

这导致我建议您需要在代码中创建并写入事件日志,以确保事件日志源相同。此外,如果通常写入事件日志,您不希望能够通过错误配置“关闭它”。

我个人的建议是开箱即用的 .NET Framework System.Diagnostics,特别是服务跟踪查看器非常适合诊断问题,特别是在多层、多线程环境中,如果使用 WCF 可以传递相关性跨层标识。

【讨论】:

    【解决方案6】:

    您可以创建自己的日志库...我做到了。

    看看 PostSharp http://www.sharpcrafters.com/,他们有一些基本日志系统的非常好的示例。

    【讨论】:

      【解决方案7】:

      http://alexworx.github.io/ALox-Logging-Library/

      是一个非常简单的库,如果您对性能有很高的要求,它非常适合。

      【讨论】:

        猜你喜欢
        • 2016-05-31
        • 2016-05-13
        • 1970-01-01
        • 2010-11-18
        • 1970-01-01
        • 2010-09-07
        • 2015-10-06
        • 2014-10-27
        • 2012-10-23
        相关资源
        最近更新 更多