使用 log4net 进行日志记录的最佳实践是什么？

Question

有人告诉我使用 log4net 将“日志记录”添加到我的代码中，问题是没有人可以及时旅行并查看日志记录需要用来解决哪些现实世界问题。

因此，是否存在一套关于记录内容的准则，以便获得合理的成本/收益权衡？

所以：

应该添加什么类型的日志记录 到一个有用的应用程序 稍后？

（代码使用了很多WCF，一侧是Winforms，另一侧是通常在同一台机器上运行的“服务器”）

——

我已经排除了AJM的答案来制作有用的博客帖子中有很多评论，但如果有人提出了一套很好的“经验法则”我可能会改变预期的答案。

Answer 1

需要记住的一件事是，虽然您的配置将处理不同级别的日志记录，但您可能会在日志调用中造成沉重的开销。例如：

// some kind of loop
// do some operations
Logger.LogDebug(myObject.GetXmlRepresentation());
// end loop

这显然只会在您有一个监听 DEBUG 日志的记录器时记录该对象，但是无论您的日志记录级别如何，构建 XML 对象的调用都会运行，并且可能会导致相当大的速度减慢。

---

正确的解决方案是：

// some kind of loop
// do some operations
if (Logger.IsDebug)
{
    Logger.LogDebug(myObject.GetXmlRepresentation());
}
// end loop

Answer 2

我发现这篇文章非常有帮助：http://blog.codinghorror.com/the- Problem-with-logging/

特别是，我认为极简主义方法确实是可行的方法。过去，我尝试记录太多日志，但这会使代码膨胀。

另外，日志条目越多越好的想法也是错误的，因为它会使日志本身膨胀。我现在认为日志记录的主要好处是提供“立足点”或对正在发生的事情的概述。如果特定区域需要更多细节，那就这样吧，但默认位置应该越少越好

Answer 3

对于此类问题，我最喜欢的信息来源是 Release It - 一本来自 Pragmatic 的书伙计们。强烈强烈推荐。

他们关于您的问题的基本观点是，日志记录应该适合操作级别的需要。运营人员最关心的是站点可能出现故障的异常情况（即连接池已满、与服务器的连接已断开等）。确保消息是不言自明的，并且非常清楚问题所在，如果适用，修复是什么。编写供人类消费的消息。

我在函数入口/出口样式日志中看不到什么意义。顶级捕获异常的堆栈跟踪很有用，记录可能发生系统崩溃的区域（即完整连接池）也很有用，就像记录系统之前崩溃的区域一样。

Answer 4

一般来说，对于日志记录，我按以下顺序添加日志记录：

1. 函数输入/退出
2. 函数内部的主要逻辑步骤
3. 所有中间计算的详细日志记录

显然，我很少到达最后一个，如果您自己动手，则第一个是微不足道的log4net 的包装器并使用处置模式，可能还有一点反射魔法。

第二个通常是在验收/集成和回归测试期间完成，因为主要逻辑流程和问题区域已被识别。在这个阶段添加日志记录也是相当少的，因为您通常知道在调试和测试时需要在哪里添加它。

第三个通常（无论如何对我来说）仅在经历回归或特别重要的代码部分中完成。

我已经为 log4net 实现了一个基本的包装器对象，它为我提供了直接日志记录功能以及一个上下文对象，该对象可以与 IDisposable 一起使用，将“进入/退出”逻辑包装在一个很好的方便的包中。

Answer 5

log4net 的一大优点是您可以将事件记录到不同的类别。默认值为“调试”、“信息”、“警告”和“错误”。我喜欢这些表示

调试 - 非常详细，包含大量调试信息。例如，SQL 查询。
信息 - 值得了解的有用信息。
警告 - 没有什么致命的，但操作员应该意识到这个问题。
错误 - 应用程序现在不稳定，日志包含诊断信息，例如异常消息和堆栈跟踪。

在代码中使用这些，例如

_log.Info("Updating object.");

会将 INFO 级别消息写入任何感兴趣的侦听器。

然后，您可以在配置中连接侦听器来处理日志消息。这是我正在使用的一个：

<log4net>
<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender">
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline" />
  </layout>
</appender>
<appender name="FileAppender" type="log4net.Appender.FileAppender">
  <file value="c:\temp\servicelog.txt" />
  <appendToFile value="true" />
  <lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline%exception" />
  </layout>
</appender>
<root>
  <level value="ERROR" />
  <appender-ref ref="ConsoleAppender" />
</root>
<logger name="Warehouse.Core">
  <level value="INFO" />
  <appender-ref ref="FileAppender" />
</logger>
</log4net>

这表示：发送到控制台的所有错误消息，从记录器 Warehouse.Core 发送到给定文件的所有信息消息。

由于类别与侦听器的连接是在配置中完成的，因此您可以在部署后更改日志记录。如果没有任何东西在监听，那么记录日志几乎不会造成性能损失。

---

关于日志记录的成本与收益，在太多日志记录（没有人会使用的巨大日志）和日志记录不足（一行显示“失败”）之间肯定存在一个最佳点。

我的策略是在 INFO 处记录可能失败的内容：外部依赖项（应用程序启动、服务调用、SQL 连接），并在 DEBUG 处记录更复杂的内容代码（业务逻辑中的诊断消息、单个 SQL 调用、某些方法调用）。

在不寻常的情况下（例如）采用通常不采用的默认值，会出现 WARN，异常情况会出现 ERROR 或 FATAL。

另外：请记住，WCF 有一个最优秀的服务跟踪查看器，它允许您“深入”到各个数据包以及堆栈两端如何处理它们。这也可以通过配置实现，无需更改代码。因此，我通常只会对 WCF 服务调用和响应进行非常简短的日志记录。

Answer 6

日志记录不是一件容易的事，但我的经验是，所有日志都应该可供责任方搜索。错误的有用目标是直接电子邮件（在某些情况下是短信）。但最终所有日志数据都应该可以在具有合理用户界面的数据库中进行搜索。

当特定帐户收到电子邮件时，可以对其进行处理并直接放入数据库中。有一些类别和处理规则如下：

• 严重错误：应该立即可用电子邮件/短信
• 未来问题：每日/每周电子邮件
• 调试信息==>每日/每周电子邮件，通知自上次以来生成了多少调试信息。

调试的内容可以通过不同的方式写入数据库，但需要考虑性能。不应在“生产模式”下将大量数据写入数据库。这应该每天/每周进行一次。最好的方法是生成一个本地文件（例如 XML 或纯文本），并在维护时间（晚上）将该文件放入数据库中。应该可以启动/停止调试会话，并且仅在调试会话完成时将调试信息写入数据库。

调试组件可以实现为 WCF 和 log2net，并直接访问数据库和/或定期放入数据库的本地文件存储。

一件事很清楚......所有错误/异常都应该记录在某处。没有什么比丢失错误消息更令人恼火的了:)

调试愉快！

Answer 7

应该向应用程序中添加哪些类型的日志记录以便以后有用？

如果您从自己的异常类抛出异常，或者更好的是，所有异常类都派生自基类，请在（基）异常构造函数中添加错误级别日志记录；使您不必记住每次接球/投掷。如果您有大量代码库，则很有用。

对于 CLR 或第 3 方异常，记录 Exception.ToString() 而不仅仅是消息，否则您会错过完整的堆栈跟踪（假设程序员没有吞下异常或重新抛出无内部异常）

在您知道的区域中重点关注调试细节或者怀疑您会遇到问题（只需询问 QA 或技术支持去哪里查找；-）

如果您遵循稳健性原则，那么当您忽略或更改输入或预期行为时，您可能需要 INFO 或 WARN 日志记录。如果您的 WCF 服务开始接收意外（但可解析）的输入，这可能会很有用。

为了确保您的应用程序性能良好，请勿在默认情况下启用调试级别日志记录的情况下运送/安装它，错误或警告可能是正确的方法。

我不同意已接受答案的最后一部分，因为 log4net 具有很棒的过滤功能；条件是您的程序员明白日志记录是有成本的（根据 CK 的答案），并且他们（以及 QA 和技术支持）了解过滤器，并且在 DEBUG 上配置所有内容是一个坏主意。如果您在 DEBUG 级别记录大型对象图、xml 文档、数据库结果等，请将其包装在一些代码中以减少费用：

if (log.IsDebugEnabled)
{
    log.DebugFormat("Loaded in {0} ms {1}", timer.ElapsedMilliseconds, dataSet.GetXml());
}

我建议您遵循 推荐 每类静态记录器方法，只是因为当您必须实际使用它并缩小范围时，它应该使日志记录更加有用关于使用过滤器的问题，例如 LoggerMatchFilter。

如果您遵循这种方法并且愿意承受（相当小的）性能损失，那么这里有一种方法，它使用堆栈跟踪为任何类创建 ILog 对象，并确保配置文件已连接以监视更改：

public static class LogFactory
{
    /// <summary>
    /// Create log whose name is the calling methods class name.
    /// </summary>
    /// <remarks>
    /// <para>
    /// Configures the log repository if it hasn't been configured before.
    /// </para>
    /// <para>
    /// Creates a debug log message right after getting the logger, this follows
    /// the log4net recommendation to log first message as early as possible.
    /// </para>
    /// </remarks>
    /// <returns>Log ready for work.</returns>
    public static log4net.ILog Create()
    {
        var method = new StackTrace().GetFrame(1).GetMethod();
        var log = log4net.LogManager.GetLogger(method.DeclaringType);

        if (log4net.LogManager.GetRepository().Configured == false)
        {
            try
            {
                new FileIOPermission(FileIOPermissionAccess.Read,
                    AppDomain.CurrentDomain.SetupInformation.ConfigurationFile)
                    .Demand();

                var configFile = new FileInfo(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);
                log4net.Config.XmlConfigurator.ConfigureAndWatch(configFile);
                log.DebugFormat("Log4net configured and watching {0}", configFile.FullName);
            }
            catch (System.Security.SecurityException e)
            {
                log.DebugFormat("Unable to watch config file due to security permissions. {0}", e.ToString());
            }
        }

        log.DebugFormat("Logging {0}", log.Logger.Name);

        return log;
    }
}

Answer 8

将事件记录到事件查看器。

明智地使用信息、调试、警告和错误。

开发时在生产中显示所有内容（使用服务器端的控制台 - 见下文），仅记录错误（可配置）

我在每个类的请求中创建一个记录器，为其提供 typeof(myClass) 但这是可选的...

我'我在 DEV 中将 WCF 作为控制台应用程序托管 - 因此在控制台中查看服务器日志也很容易，但是一旦它成为服务，您就必须使用事件查看器......

啊 - 如果您比较的话，它非常快它到 WCF“调用时间”（从客户端调用到服务器），因此它并不会真正影响您的时间，除非您有类似疯狂的日志（例如 nHibernate））

Answer 9

对于 WCF 来说，可能有更好的方法来做到这一点；对于 WinForms，您可以考虑查看 PostSharp。这将允许您记录方法调用，而不会使您的代码混乱。在幕后您仍然可以使用优秀的 log4net。

警告：我自己没有使用过它；我在代码训练营中看到过一个令人印象深刻的演示。