日志记录是记录信息的通用术语-跟踪是用于调试的特定形式的日志记录。
在.NET中，System.Diagnostics.Trace和System.Diagnostics. VBA对象允许简单地记录到许多“事件侦听器”，您可以在app.dll中配置这些侦听器。您还可以使用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.NET2+中，还有一个更完整的日志框架，称为健康监视。
Log 4 Net是一种比内置的Trace，甚至ASP Health Monitoring更丰富，更灵活的跟踪或日志记录方式。类似于诊断。跟踪您在配置中配置的事件侦听器（“appenders”）。对于简单的跟踪，使用就像内置的Trace一样简单。使用Log 4 Net的决定取决于您是否有更复杂的需求。

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");
    }
}

IMO
日志记录不应该被设计用于开发调试（但它不可避免地会以这种方式使用）
日志记录应该被设计用于 * 操作 * 监控和故障排除--这是它存在的理由。
跟踪应该被设计用于开发调试和性能调优。如果在现场可用，它可以用于真正的低级别操作故障排除，但这不是它的主要目的
考虑到这一点，我过去见过的（以及设计/实现的）最成功的方法都没有将两者合并在一起。最好将这两个工具分开，每个工具尽可能地完成一项工作。

log 4 net非常适合这两种情况。我们通过使用DEBUG日志级别来区分用于发布后诊断的日志和用于开发目的的“跟踪”。具体来说，开发人员使用Debug()记录他们的跟踪输出（只在开发过程中感兴趣的内容）。我们的开发配置将Level设置为DEBUG：

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

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

<level value="INFO" />

这将从发布日志中删除所有DEBUG输出，但保留INFO/WARN/ERROR。
还有其他log 4 net工具，如过滤器，分层（按名称空间）日志记录，多个目标等，通过我们发现上述简单的方法相当有效。

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

我会说是的日志记录是确定过去发生了什么的唯一方法-如果客户打电话说某些事情没有按预期发生，如果没有日志，您所能做的就是耸耸肩并尝试重现错误。有时这是不可能的（取决于软件的复杂性和对客户数据的依赖）。
还有一个用于审计的日志记录问题，可以编写一个日志文件，其中包含有关用户正在执行的操作的信息-因此您可以使用它来缩小调试问题的可能性，甚至验证用户的声明（如果你得到一个报告，系统坏了，xyz没有发生，你可以在日志中查找操作员未能启动该进程，或者没有点击正确的选项使其工作）
然后是用于报告的日志记录，这是大多数人认为日志记录的目的。
如果您可以定制日志输出，那么将所有内容放入日志中，并减少或增加写入的数据量。如果你能动态地改变输出电平，那就太完美了。
您可以使用任何方法来写入日志，但要考虑性能问题。我发现附加到文本文件是最好的，最便携的，最容易查看的，并且（非常重要的是）在需要时最容易检索。

logging！=调试
有时候，保存日志文件对于解决客户端的问题是必要的，它们可以证明服务器端发生了什么。

此外，考虑记录或跟踪哪些信息。对于敏感信息来说尤其如此。
例如，虽然通常可以记录错误，
“用户'X'试图访问，但由于密码错误而被拒绝”，
不能记录以下错误：
“用户'X'尝试访问但被拒绝，因为密码'secret'不正确。”
将这些敏感信息写入跟踪文件（并在您要求客户/用户启用跟踪以进行生产中的扩展故障排除之前，通过“某种方式”警告客户/用户这一事实）* 可能 * 是可以接受的。然而，对于日志记录，我总是把它作为一个政策，这样的敏感信息是永远写入（即。级别INFO和以上的log 4 net发言）。
当然，这必须通过代码审查来执行和检查。