日志框架，好主意吗？答案

【问题标题】：Logging Framework, a good idea?日志框架，好主意吗？
【发布时间】：2009-10-22 09:37:46
【问题描述】：

首先，为主观的标题道歉。这是一个直接的问题。

目前我正在开发一套工具：

一个 C# Windows 服务，主要用于维护一个 Oracle 数据库。
一个 C# Windows 服务，（它将是在多个节点站点上使用）处理数据库的内容。
一个 ASP.NET Web 界面便于管理整体 “系统”

目前 Windows 服务已开发为控制台应用程序（以简化调试/开发），我正在将这些转换为服务。在使用这些服务测试了几天之后，我发现我想增加日志记录的粒度。我发现我想念 Console.WriteLine() 并且我想为这种类型的输出提供一个备用日志源，比如平面文件。这让我想到，“我应该使用框架，还是已经够用了？”

我提到我正在开发的方面的原因是为了提供对我的情况的洞察力。创建了一个“核心”DLL，它在所有组件中通用，抽象了应用程序和数据库之间的交互层。正是在这个 DLL 中创建了一个类，该类将尝试“记录到数据库中的表”，否则在失败时“记录到本地事件日志”。就是这样，这就是日志的范围。

在上述工具中，有多个日志记录实例与：

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

虽然很基本，但这种方法确实利用反射来识别错误的来源。

我的问题

查看我当前的日志记录解决方案，就其功能以及如何与我的所有解决方案集成而言，它似乎“足够”了。但是，我一直在研究日志框架（尤其是 log4net），它们的功能给我留下了深刻的印象。如果将来需要，添加另一种输出格式（例如 SMTP 服务器）的能力对我来说听起来很酷！ :)

我想知道迁移到框架（如 log4net）的好处？我需要在多大程度上调整我的代码？我是否只是在看另一边更绿的草？最后，但可能最重要的是，我做对了吗？我是否应该将我的 Log 类的功能添加到“LogDebug”并完成它？我想做的最后一件事是彻底检修我的套件，只是为了一个“基本”功能，但如果还有其他好处（设计、依赖、良好实践等）我很感兴趣。

谢谢，

【问题讨论】：

您的问题标题中有错字。 ;)
谢谢！诵读困难再次发作。 :)
越早越好。我继承了一天失败的自定义日志记录代码，并停止了所有日志。设想。我已经切换到log4net 并且从未回头 - 它在各方面都更好。

标签： c# logging log4net

【解决方案1】：

是的。使用现有的、经过验证的日志框架（例如 Log4net）是个好主意。

Log4Net 可在运行时配置（非常适合跟踪生产代码中的问题）。

正如评论者指出的那样，它的使用也非常简单。

【讨论】：

我猜你因为没有回答问题而被否决了。
使用起来也非常简单。 Logger.Warn|WarnFormat|Error|Debug（“消息”，可选异常）。输出到多个目的地。出错时静默失败（不会将异常抛出到您的代码中）。可以将不同级别的警告指向不同的地方。功能非常齐全。不要自己动手。
不-这是问题的标题。问题是“我想知道迁移到框架（如 log4net）的好处是多少？我需要在多大程度上调整我的代码？我是否只是在看另一边的绿草最后，但可能最重要的是，我做对了吗？我是否应该将我的 Log 类的功能添加到“LogDebug”并完成它？我想做的最后一件事是彻底检查我的套件，只是为了一个“基本”功能，但如果有其他好处（设计、依赖、良好实践？等）我......”

【解决方案2】：

在多个远程系统上运行代码时，适当的日志记录特别有用，据我记得，log4net 可以让您将日志发送到远程 syslog 服务器，而无需太多编码开销（这意味着您可以在一台机器上查看来自所有机器的日志集中的地方）这样做将大大减少您获取与系统错误或问题相关的信息所需的时间，并且还应该让您了解问题的普遍程度。

正如其他帖子中提到的，log4net 还允许多个附加程序和多个日志级别，因此确定您想要某些日志信息的位置（即在数据库或本地平面文件中，嘿 log4net 甚至可以让您通过 telnet 吐出日志) 要存储是绝对轻而易举的事。

至于实现它，有几个很好的网站会告诉你设置。如何实际使用 log4net 为您提供的日志记录对象是一种架构选择，但您可以简单地更改对象的构造函数以获取 log4net 对象，然后在该对象中，只需像使用 Console.WriteLine 一样使用 log4net 对象.

我发现教程系列here 特别有用，而且它还将比我在这里更深入地介绍配置 log4net 的好处和不同方式。

【讨论】：

虽然这里的很多答案都强调了框架的好处，但实际上只有这个答案让我得出了一个结论。多亏了里面的教程，我发现实现相对“无风险”，而且你指出了一些我可能需要但我自己还没有意识到的极好的情况。谢谢。

【解决方案3】：

是的，您肯定想要使用日志框架。日志框架将允许您：

为不同的记录器实例设置记录级别。
为每个不同的记录器实例设置“附加器”或输出。

也许，更重要的是，如果您使用日志框架，很容易将日志框架的一个实现换成另一个（可能是一个简单地丢弃消息的空实现）；然而，如果您直接编写所有日志记录语句，那么替换实现将是一场噩梦。

【讨论】：

【解决方案4】：

我认为你应该使用 Log4net，只是因为重复使用总是比构建自己的东西更好。 log4net 已经被很多开发者使用并且相当成熟。

想想您的维护前景；一两个月后，您可能需要稍微调整您的自定义日志记录类，添加一些多线程支持等。当您修复日志记录类产生的错误时，您将错过 Log4net。

【讨论】：

【解决方案5】：

最大的好处之一是不必自己维护代码。大多数时候，日志框架比你自己的解决方案有更多的功能。因为它们非常专注于日志记录，所以这些框架通常在功能和实现方式上都非常完整。然后是可靠性；没有什么比日志框架更糟糕的了，因为它被窃听了。 ;)

以ELMAH 为例，用于 ASP.net 应用程序。它还包括通知、导出到各种目标格式等。这些东西非常方便，但除非你真的需要它，否则你永远不会自己构建。

显然需要对代码进行多少更改取决于您的代码和选择的框架。这很难说。

【讨论】：

【解决方案6】：

我要向 NLog (http://nlog-project.org/home) 大声疾呼，因为它不受大多数 oss .Net 库的“直接 Java 端口 - 然后重写”综合症的影响。

对我们来说一些关键的好处是非常快的 Logger.IsFooEnabled（易失性读取）和系统的整体性能。

虽然各有特色，但我个人更喜欢将 NLog 用于我的项目（以及我的一些客户）。

干杯，弗洛里安

【讨论】：

【解决方案7】：

使用像 Log4Net 这样好的日志框架的优势在于，它们对您的代码的影响很小，就您必须更改的代码行而言（换句话说，您只需更改每个现有的日志行）。

此外，如果您担心在更改框架时会更改代码，或者如果您想推出自己的代码，那么您始终可以创建自己的接口到 a 日志框架。然后你只需要在一个地方更改你的代码。

【讨论】：

关于创建界面的一个非常好的观点，这正是我们在工作中所做的......

【解决方案8】：

我认为系统管理员希望服务记录到 Windows 中的应用程序事件日志。

查找 System.Diagnostics.EventLog，虽然 log4net 也会写入它..

【讨论】：

【解决方案9】：

log4j website 中的初始声明可能对您的一些问题有所帮助，基本原理与 log4net 相同：

使用 log4j 可以启用在运行时记录而不修改应用程序二进制文件。 log4j 包的设计使这些语句可以保留在交付的代码中不会产生沉重的表现成本。记录行为可以是通过编辑配置来控制文件，无需接触应用程序二进制。

使用记录器层次结构可以控制哪个日志语句任意输出细粒度但也大方便。这有助于减少记录的数量输出和最小化成本记录。

在这种情况下，显然没有必要重新发明轮子。大多数 Logging 框架都比较简单，因此更改的范围很可能取决于您现有程序的大小。

【讨论】：

除了海报使用.NET ;)
@Mitch，关于 log4j 的陈述仍然适用，因为 log4net 只是 log4j API 的 C# 实现。

【解决方案10】：

如果您正确编写记录器类，它将很容易满足您的任何需求。任何框架都可以用许多特性给你留下深刻印象，但另一个框架是调试过程中的另一个变量，因为它可能会给你一个不存在的错误，或者结合你的应用程序本身就会出错。如果您准备好对开源软件项目进行 beta 测试，这很好......

在您的位置，我将编写日志类，该日志类能够根据已知框架具有的功能列表来扩展您认为对您的项目感兴趣的功能。我认为将某些内容记录到文件然后通过 smpt 发送没有任何问题，只需一个小函数即可完成这项工作。

此外，您可以编写自己的非常抽象的类并将您的基本代码放在那里，如果您需要使用外部框架来测试您的类，那么您可以在对代码影响最小的情况下使用它。看看那里的框架是如何在代码级别实现的。

考虑一下，当您现在只需要记录其中的一小部分时，您将需要学习如何正确使用这些框架......

【讨论】：