追踪与日志记录，log4net如何适配？

Question

我想知道日志和追踪之间的区别是什么。

差异基本上是指追踪提供了更详细的日志，使开发人员能够在运行时调试应用程序吗？

我一直在使用log4net进行记录实验。现在我想知道是否应该同时进行追踪，是否可以/应该使用log4net来实现追踪。 我应该与log4net进行追踪吗？ log4net记录器有某些跟踪级别吗？我是否应该为调试和追踪目的使用不同的日志级别或者使用相同的级别都可以？ 你能举个简单的例子说明如何对一个简单的方法进行日志记录和追踪吗？

编辑： 尽管下面有一些有帮助的答案，但我仍然不确定我应该如何进行追踪和记录。

我在我的业务层中有以下方法，我想为其添加日志/跟踪。我想知道如何有效地实现它。以下方法在日志/追踪方面是否可接受？我的日志消息是否应该是Info类型而不是Debug？我正在记录的Debug消息是否被视为跟踪？你会如何改变它？

IEnumerable<Car> GetCars()
{
   try
   {
      // 记录调试信息
      logger.Debug("获取车辆");
      // 获取汽车数据并转换为业务对象
      IEnumerable<Car> cars = CarAccessor.GetCars().ConvertAll(DataAccessToBusinessConverter);
      // 记录汽车数量
      logger.Debug("共获取到" + cars.Count + "辆车"); 
   } catch (Exception e) {
      // 记录异常信息
      logger.Error("获取车辆时出错", e);
      // 抛出异常
      throw new Exception("获取车辆时出现意外错误");
   }
}

- Xerx

Answer 1

记录信息的通用术语是“日志记录”，“跟踪”是用于调试的特定形式的日志记录。

在.NET中，System.Diagnostics.Trace和System.Diagnostics.Debug对象允许将简单日志记录到多个“事件侦听器”中，您可以在app.config中配置这些侦听器。 您还可以使用TraceSwitches来配置和过滤（例如在错误和信息级别之间）。

private void TestMethod(string x)
{
    if(x.Length> 10)
    {
        Trace.Write("String was " + x.Length);
        throw new ArgumentException("String too long");
    }
}

在ASP.NET中，有一个特殊版本的Trace（System.Web.TraceContext）会写入到ASP页面底部或Trace.axd中。 在ASP.NET 2+中，还有一个更完整的日志框架叫做Health Monitoring。

Log4Net是比内置的Trace或者甚至ASP Health Monitoring更丰富和灵活的追踪或记录方式。像Diagnostics.Trace一样，在配置文件中配置事件监听器（“appenders”）。对于简单的跟踪，使用起来与内置Trace类似。使用Log4Net的决定取决于您是否有更复杂的要求。

private void TestMethod(string x)
{
    Log.Info("String length is " + x.Length);
    if(x.Length> 10)
    {
        Log.Error("String was " + x.Length);
        throw new ArgumentException("String too long");
    }
}

- martin

---

值得指出的是，Log4Net有一个log4net.Appender.TraceAppender，它可以像Trace类一样将输出发送到Visual Studio输出窗口。在翻译过程中，我已经尽力保持原意并使语言更加通俗易懂，但没有添加任何解释或其他内容。 - ronaldwidha

Answer 2

在我看来...

日志记录不应该仅用于开发调试（但它总是被用于这个目的）
日志记录应该设计用于运营监控和故障排除——这是它存在的原因。

追踪应该设计用于开发调试和性能优化。如果在现场可用，也可以用于真正低级别的操作故障排除，但这不是其主要目的。

基于这一点，我见过的（并且过去设计/实现的）最成功的方法不将两者结合在一起。最好将这两个工具分开，每个工具都尽可能地完成一个任务。

- Kevin Little

Answer 3

log4net非常适用于两者（译注：指日志和跟踪）。通过使用DEBUG日志级别，我们区分有用于发布后诊断的日志记录和开发目的的“跟踪”。具体来说，开发人员使用Debug()记录其跟踪输出（仅在开发期间感兴趣的内容）。我们的开发配置将级别设置为DEBUG：

<root>
        <level value="DEBUG" />
        ...
</root>

产品发布前，将级别更改为“INFO”：

<level value="INFO" />

这将删除发布日志中的所有DEBUG输出，但保留INFO / WARN / ERROR。

还有其他log4net工具，如过滤器、分层（按命名空间）记录、多个目标等，但我们发现上述简单方法非常有效。

- Bob Nadler

---

那么我理解追踪和日志记录之间的区别只是美学上的区别，级别为debug的日志条目确实是追踪吗？ - Xerx

大多数时候，我认为这是正确的。例如，跟踪实时设备接口之类的专业情况下，像log4net这样的通用工具可能不是最佳选择。顺便说一句：我们使用DEBUG是因为它是预定义的级别。您也可以定义自己的级别，例如TRACE。 - Bob Nadler

Answer 4

日志记录(Logging)与跟踪(Tracing)不同。它们应该是具有不同性能特征的不同库。事实上，我自己编写了一个跟踪库，其独特属性在于当启用跟踪的方法因异常而离开时，它可以自动跟踪异常。此外，您还可以以优雅的方式解决在代码中特定位置触发异常的问题。

- Alois Kraus

Answer 5

我认为是的。日志记录是唯一确定过去发生了什么的方法 - 如果客户打电话说某些事情没有按预期发生，没有日志，你只能耸耸肩膀并尝试重现错误。有时这是不可能的（取决于软件的复杂性和对客户数据的依赖程度）。

还有一个问题是审计日志记录，可以编写包含用户正在执行的信息的日志文件 - 因此，您可以使用它来缩小调试问题的可能性，甚至验证用户的声明（如果您收到报告称系统已损坏，则可以查看日志以查明操作员未能启动进程或未单击正确的选项使其工作）。

然后是大多数人认为日志记录是用于报告的日志记录。

如果您可以定制日志输出，则将所有内容放入日志中并减少或增加要写入的数据量。如果您可以动态更改输出级别，那就太完美了。

您可以使用任何编写日志的手段，但要考虑性能问题。我发现将其附加到文本文件中是最好的、最便携的、最易于查看的，并且（非常重要的）在需要时最容易检索的方法。

- gbjbaanb

---

+1. 我同意。很多时候连客户都没有打电话，只是匿名的网站用户出现错误并离开了该网站。这时需要监视日志才能知道应用程序中存在错误。 - Jonas Stensved

Answer 6

记录日志并非调试

有时候保留日志文件是解决客户问题的必要手段，它们可以证明服务器端发生了什么事情。

- Karl

Answer 7

此外，考虑记录或追踪哪些信息。特别是对于敏感信息。

例如，虽然记录错误状态为“用户'X'尝试访问但因密码错误而被拒绝”可能通常可以接受，

但记录错误状态为“用户'X'尝试访问但因密码'secret'不正确而被拒绝”是不可以的。

也许将这样的敏感信息写入跟踪文件（并在生产环境中请求客户/用户启用跟踪以进行扩展故障排除之前，通过“某种方式”告知其这一事实）可能是可以接受的。然而对于日志记录，我始终把这样的敏感信息作为一项方针，永远不写入（即log4net中的INFO及以上级别）。

当然，必须通过代码审查来执行和检查。

- Christian.K