跟踪与日志记录以及log4net如何适应？-Java 学习之路

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

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

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

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

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

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

在.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 监控的更全面的日志框架 .

与内置的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");
    }
}
```
回复于 2024-04-25T21:59:55+08:00
13

IMO ...

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

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

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

回复于 2024-04-25T21:59:55+08:00
0
log4net非常适合两者 . 我们通过使用DEBUG日志记录级别来区分对发布后诊断有用的日志记录和用于开发目的的"tracing" . 具体来说，开发人员使用 Debug() 记录他们的跟踪输出（在开发过程中仅感兴趣的事情） . 我们的开发配置将Level设置为DEBUG：
```
<root>
        <level value="DEBUG" />
        ...
</root>
```
在产品发布之前，级别更改为“INFO”：
```
<level value="INFO" />
```
这将从发布日志记录中删除所有DEBUG输出，但保留INFO / WARN / ERROR .

还有其他log4net工具，如过滤器，分层（按命名空间）记录，多个目标等，我们发现上述简单方法非常有效 .
回复于 2024-04-25T21:59:55+08:00
8

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

回复于 2024-04-25T21:59:55+08:00
0

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

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

然后是报告记录，这是大多数人认为记录的目的 .

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

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

回复于 2024-04-25T21:59:55+08:00
11

logging！=调试

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

回复于 2024-04-25T21:59:55+08:00
25

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

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

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

记录错误说明不行

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

将这样的敏感信息写入跟踪文件可能是可以接受的（并且在您要求他为生产环境中的扩展故障排除启用跟踪之前，通过"some means"警告客户/用户该事实） . 然而，对于日志记录，我总是将其作为一种策略来写入这样的敏感信息（即，log4net中的级别INFO及以上说话） .

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

回复于 2024-04-25T21:59:55+08:00

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

7 回答

相关问题