跟踪与日志记录以及log4net如何适应?

时间:2008-10-05 18:07:40

标签: .net logging log4net tracing

我想知道记录和跟踪之间的区别是什么。

差异基本上是跟踪是更详细的日志,为开发人员提供了在运行时调试应用程序的工具吗?

我一直在尝试使用log4net并进行日志记录。现在我想知道我是否应该进行跟踪以及是否可以/应该使用log4net进行此目的。 我应该使用log4net进行跟踪吗?log4net记录器是否有一些跟踪级别?我应该使用不同的日志级别进行调试和跟踪,还是可以使用相同的? 你能给出一个简单的例子来说明如何对一个简单的方法进行记录和跟踪吗?

编辑: 尽管下面有一些有用的答案,我仍然不确定我应该如何进行跟踪与日志记录。

我的Business层中有以下方法,我想向它添加日志记录/跟踪。我想知道如何有效地做到这一点。在记录/跟踪方面,以下方法是否可以接受?日志消息应该是Info类型而不是Debug类型吗?我记录的调试消息是否被视为跟踪?你会如何改变它?


IEnumerable<Car> GetCars()
{
   try
   {
      logger.Debug("Getting cars");
      IEnumerable<Car> cars = CarAccessor.GetCars().ConvertAll(DataAccessToBusinessConverter);
      logger.Debug("Got total of " + cars.Count + " cars"); 
   } catch (Exception e) {
      logger.Error("Error when getting cars", e);
      throw new Exception("Unexpected error when getting cars");
   }
}

7 个答案:

答案 0 :(得分:26)

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

在.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。

与内置的Trace甚至ASP Health Monitoring相比,Log4Net是一种更丰富,更灵活的跟踪或记录方式。与Diagnostics.Trace一样,您可以在config中配置事件侦听器(“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");
    }
}

答案 1 :(得分:13)

IMO ...

记录应设计用于开发调试(但不可避免地以这种方式使用)
记录应设计用于操作监控和故障排除 - 这是其存在的理由。

跟踪应该设计用于开发调试&amp;性能调整。如果在现场可用,它可以用于真正的低级操作故障排除,但这不是它的主要目的

鉴于此,我见过的最成功的方法(和设计/实施)过去,将两者结合在一起。最好将两个工具分开,每个工具尽可能地完成一项工作。

答案 2 :(得分:11)

log4net非常适合两者。我们通过使用DEBUG日志记录级别来区分对发布后诊断有用的日志记录和用于开发目的的“跟踪”。具体而言,开发人员使用Debug()记录他们的跟踪输出(在开发过程中仅感兴趣的事情)。我们的开发配置将Level设置为DEBUG:

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

在产品发布之前,级别更改为“INFO”:

<level value="INFO" />

这将从发布日志记录中删除所有DEBUG输出,但保留INFO / WARN / ERROR。

还有其他log4net工具,如过滤器,分层(按名称空间)记录,多个目标等,我们发现上述简单方法非常有效。

答案 3 :(得分:8)

Logging is not Tracing。这两个应该是具有不同性能特征的不同库。事实上,我自己编写了一个tracing library的唯一属性,当启用了跟踪的方法留下异常时,它可以自动跟踪异常。除此之外,还可以解决in an elegant way问题,以触发代码中特定位置的异常。

答案 4 :(得分:4)

我会说是的。记录是确定过去发生的事情的唯一方法 - 如果客户打电话并说某些事情未按预期发生,没有记录,您只能耸耸肩并尝试重现错误。有时这是不可能的(取决于软件的复杂性和对客户数据的依赖)。

还存在记录审计的问题,可以编写包含用户正在做什么的信息的日志文件 - 因此您可以使用它来缩小调试问题的可能性,甚至验证用户的声明(如果你得到一个报告说系统坏了,xyz没有发生,你可以查看日志以找出操作员未能启动该过程,或者没有点击正确的选项使其工作)

然后有报告记录,这是大多数人认为记录的目的。

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

根据性能问题,您可以使用任何编写日志的方法。我发现附加到文本文件是最好的,最便携的,最容易查看的,并且(非常重要)最容易在需要时检索。

答案 5 :(得分:0)

logging!= debugging

有时保留日志文件是解决客户端问题所必需的,它们证明了服务器端发生了什么。

答案 6 :(得分:0)

另外,请考虑记录或跟踪的信息。对于敏感信息尤其如此。

例如,虽然通常可以记录错误说明

“用户'X'试图访问但由于密码错误而被拒绝”,

记录错误说明

是不行的

“用户'X'试图访问但被拒绝,因为密码'秘密'不正确。”

可能可以接受将此类敏感信息写入跟踪文件(并在您要求他为生产中的扩展故障排除启用跟踪之前,通过“某种方式”警告客户/用户该事实) )。但是对于日志记录,我总是把它作为一种策略,这样的敏感信息从不写入(即log4net中的INFO及以上级别)。

当然,这必须通过代码审查来强制执行和检查。