为什么存在TRACE级别，何时应该使用它而不是DEBUG？

在Log4J，Slf4J和Java中的其他几个日志记录框架中，您有两个“开发人员”级别用于记录日志：

• 调试
• 跟踪

我了解DEBUG的作用，因为解释很清楚：

调试级别指定细粒度的信息事件，这些事件对于调试应用程序最有用。

但是TRACE级别对其用例不是很明确：

与调试相比，TRACE级别指定的信息事件更详细

（来源：log4J JavaDoc）

这没有告诉我如何或何时使用TRACE。有趣的是，这不是syslog标准中定义的严重性级别。搜寻TRACE和DEBUG之间的区别似乎只是返回“使用DEBUG，哦，也有TRACE”。我找不到TRACE级别的特定用例。我能找到的最好的东西是这个古老的Wiki页面，讨论了该级别存在的优点。

作为一名建筑师，这在我脑海中引发了许多旗帜和问题。如果一个年轻的开发人员要求我将TRACE添加到我的体系结构中，我会用以下问题轰炸他：

• 应该使用TRACE而不是DEBUG记录的一些信息示例是什么？
• 通过记录该信息可以解决什么具体问题？
• 在这些示例中，已记录信息的属性有哪些可清楚地区分TRACE级别而不是DEBUG级别的记录？
• 为什么该信息必须通过日志基础结构？
  • 将这些信息保留在日志日志中而不只是使用这些日志有什么好处System.out.println？
  • 为什么最好为此使用日志而不是调试器？
• 在TRACE级别进行日志记录的典型示例是什么？
  • 在示例中，通过以TRACE级别而不是DEBUG进行记录获得了哪些具体收益？
  • 为什么这些收益很重要？
  • 相反：通过将其记录在TRACE而不是DEBUG上可以避免什么问题？
  • 我还能如何解决这些问题？为什么在TRACE级别上进行日志记录比其他解决方案更好？
• TRACE级别的日志语句是否应保留在生产代码中？为什么？

但是考虑到它存在于大多数主要框架中，我猜它对某些事情有用吗？那么... TRACE的用途是什么，它与DEBUG有何区别？

应使用TRACE而不是DEBUG记录的信息示例是什么？

如果我的算法需要执行多个步骤，那么跟踪级别将以最佳级别显示有关每个步骤的信息。诸如每一步的文字输入和输出之类的事情。

通常，跟踪将包括所有调试（就像调试包括所有警告和错误一样）。

通过记录该信息可以解决什么具体问题？

你需要一些调试输出方式太多的数据来登录特定的身材之外，当你瞄准特定的事情，不在乎错误或其他记录信息（因为跟踪信息的量会掩盖它们）。在某些记录器中，您只会将某个模块设置为仅跟踪级别。

在这些示例中，已记录信息的属性有哪些可清楚地区分TRACE级别而不是DEBUG级别的记录？

通常，跟踪级别的日志记录无法持续运行，因为它会大大降低应用程序的性能，并且/或者创建大量的日志数据，由于磁盘/带宽的限制，这些日志数据是不可持续的。

调试级别的日志记录通常可以打开更长时间，而不会导致应用程序无法使用。

为什么该信息必须通过日志基础结构？

不必。一些框架具有单独的跟踪记录器。

通常，它以日志结尾，因为跟踪记录器和普通记录器在写入磁盘/网络，错误处理，日志轮换等方面有相似的需求。

为什么最好为此使用日志而不是调试器？

因为调试器可能无法连接到有问题的机器。您可能不甚了解，甚至不知道在哪里设置断点或单步执行代码。您可能无法在调试器中可靠地重现该错误，因此请使用日志“如果发生”来捕获该错误。

但它们只是名字。像其他任何标签一样，它们只是人们穿上东西的名字，通常对不同的人意味着不同的东西。而且，标签本身不如标签所指的肉味那么重要。

请特别注意slf4j特别建议不要使用trace（http://slf4j.org/faq.html#trace）：

简而言之，尽管我们仍然不鼓励使用TRACE级别，因为存在替代方案，或者因为在许多情况下，由于人们不断要求TRACE级别的日志请求是浪费的，所以我们决定屈从于大众需求。

就个人而言，我的期望是跟踪以记录所有内容（例如，即使是诸如“在Y时刻输入带有参数A，B，C的输入函数MyFunc之类的东西”）。不利的一面是，这不仅令人难以置信的嘈杂，而且还容易引起磁盘空间问题。我希望在正常操作期间禁用此类日志记录。好处是，这可以为您提供类似于在附加调试器不太实际的情况下单步执行程序时所获得的信息级别。

通常，我发现跟踪通常比其他方法更费力。

通常，调试级别是完全任意的，并且在语言，库和公司之间可能会有所不同。

话虽如此，这是我如何看待它们的用法：

TRACE：用于显示逻辑级程序流。输入了功能？“ if”语句选择主分支还是“ else”分支？那是追踪的候选人。换句话说，跟踪日志记录通常用于指定“您在这里”。这在可能记录错误或其他信息的其他记录语句的上下文中很有用。跟踪日志记录可以帮助在代码中精确定位错误或其他级别记录的其他事件的位置。

DEBUG：用于转储变量状态，特定的错误代码等。例如：Web服务可能返回错误代码809214，当应用程序告知用户“通信失败”时，可以记录该错误代码。想象一下，开发人员在错误发生很长时间之后就从用户系统接收日志，并且想知道“ 为什么会发生错误？” 在调试级别记录日志是一件好事。另一个例子是，如果错误始终在生产中发生，但很难重现，请在有问题的模块中调试某些变量或事件的日志，以帮助告知开发人员错误发生时的程序状态，以帮助进行故障排除。

通常，可以将应用程序配置为以给定级别（或更高级别）登录。例如，跟踪通常是最低级别的：在该级别进行记录将记录所有内容。调试级别将省略跟踪，但包括高级级别（例如，警告和错误）。

隔离日志级别的好处是控制记录的数量。对于复杂的应用程序，跟踪日志记录可能会记录大量数据，其中大部分在大多数情况下是无用的。最好仅记录关键信息（可能是一些启动信息，然后是错误），除非有人试图确定导致错误的原因。此外，这通常仅在生产环境中有用，而没有调试器和其他开发工具。

没有真正的限制，没有规则说您必须以​​某种方式登录。仅遵循或不遵循某些库或应用程序的广泛约定。

我认为Telastyn的出色回答可以归结为我的经验法则：

• DEBUG 日志记录必须能够在生产中使用（但通常仍处于关闭状态）
• TRACE 不允许在生产中使用日志记录（对于特定的/短期会话除外）

这是我的经验法则

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

这背后的假设是操作团队将

• 始终将生产设置为日志级别的信息
• 可能将生产设置为日志级调试
• 从未将生产设置为日志级跟踪

有了这个假设，这就是您作为开发人员可以使用日志级别的方式...

问题＃1）不会过度降低生产性能

debug解决＃1。作为开发人员，您就是在平衡生产过程中可能需要的信息的同时，努力避免使机器减速的噪音太大。您说的是“（如果需要）不断将其记录在生产中是个好主意。”

问题＃2）开发时具有详细信息

trace解决问题2。您完全不必担心它将对生产机器产生什么影响，但是您现在在开发代码时就需要该信息。您说的是“我不保证始终在生产中记录此信息是个好主意。”

当然（如其他人所说），这些事情是任意的。因此，只需确保您的开发团队（和操作/监视团队-因为他们也是您的日志记录的用户）就某件事达成一致即可。

在TRACE级别进行日志记录的典型示例是什么？

一种方法的输入/退出日志。这些日志可帮助您跟踪程序的流程，并在以下情况下非常有用：

1. 该程序突然崩溃-通过查看日志的最后一行，您可以确切地知道它崩溃了哪个功能

2. 一些流氓功能通过吸收异常而静默失败

它们需要一个单独的TRACE级别，而不仅仅是使用DEBUG，因为为代码库中的每个方法启用ENTRY / EXIT日志将产生大量额外的日志，即使在DEBUG上下文中，这些日志也总是不合理的。