50

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

本质上的区别是跟踪是更详细的日志，为开发人员提供了在运行时调试应用程序的工具吗？

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

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

我的业务层中有以下方法，我想向它添加日志记录/跟踪。我想知道如何有效地做到这一点。以下方法在日志记录/跟踪方面是否可以接受？日志消息应该是 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");
   }
}
4

7 回答 7

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。

Log4Net 是一种比内置 Trace 甚至 ASP Health Monitoring 更丰富、更灵活的跟踪或日志记录方式。像 Diagnostics.Trace 一样，您可以在 config.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");
    }
}
于 2008-10-05T19:45:39.807 回答
13

IMO...

日志不应该设计用于开发调试（但它不可避免地会以这种方式使用）
日志应该设计用于操作监控和故障排除——这是它存在的理由。

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

鉴于此，我过去见过（和设计/实施）的最成功的方法并没有结合两者在一起。最好将这两个工具分开，每个工具都尽可能地完成一项工作。

于 2008-10-05T19:33:23.153 回答
11

log4net 非常适合两者。我们通过使用 DEBUG 日志级别来区分对发布后诊断有用的日志记录和用于开发目的的“跟踪”。具体来说，开发人员使用Debug(). 我们的开发配置将 Level 设置为 DEBUG：

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

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

<level value="INFO" />

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

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

于 2008-10-05T19:18:24.527 回答
8

记录不是跟踪。这两个应该是具有不同性能特征的不同库。事实上，我自己编写了一个跟踪库，具有独特的属性，当启用跟踪的方法出现异常时，它可以自动跟踪异常。除此之外，还可以优雅地解决在代码中特定位置触发异常的问题。

于 2010-07-21T10:58:58.673 回答
4

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

还有一个审计日志的问题，可以编写一个日志文件，其中包含有关用户正在做什么的信息 - 因此您可以使用它来缩小调试问题的可能性，甚至验证用户的声明（如果您得到系统损坏的报告，xyz 没有发生，您可以查看日志以找出操作员未能启动进程，或者没有单击正确的选项使其工作）

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

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

您可以使用任何写入日志的方式，但会遇到性能问题。我发现附加到文本文件是最好的、最便携的、最容易查看的，并且（非常重要的是）在需要时最容易检索。

于 2008-10-05T18:26:26.330 回答
0

记录！=调试

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

于 2008-10-05T18:10:27.610 回答
0

此外，请考虑记录或跟踪哪些信息。对于敏感信息尤其如此。

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

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

记录错误说明是不行的

“用户‘X’试图访问但被拒绝，因为密码‘secret’不正确。”

将此类敏感信息写入跟踪文件可能是可以接受的（并在您要求客户/用户启用跟踪以在生产中进行扩展故障排除之前，通过“某种方式”警告客户/用户该事实）。但是对于日志记录，我始终将此类敏感信息作为永远不会写入的策略（即 log4net 中的 INFO 及以上级别）。

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

于 2008-10-06T06:07:40.690 回答