DEBUG
I了解DEBUG的功能，因为其解释很清楚：
DEBUG级别指定细粒度的信息性事件，这些事件对于调试应用程序最有用。
但TRACE级别对其用例并不十分明确：
TRACE级别指定的信息事件比DEBUG
/>（来源：log4J JavaDoc）
这没有告诉我如何或何时使用TRACE。有趣的是，这不是syslog标准中定义的严重性级别。搜寻TRACE和DEBUG之间的区别似乎只是返回“使用DEBUG，哦，也有TRACE”。我找不到TRACE级别的特定用例。我能找到的最好的东西是这个古老的Wiki页面，讨论了该关卡存在的优点。
作为一名建筑师，这在我脑海中引发了很多标记和问题。如果一个年轻的开发人员要求我将TRACE添加到我的体系结构中，我会问他以下问题：
应该用TRACE而不是DEBUG记录的一些信息示例是什么？
通过记录该信息可以解决什么具体问题？
在那些示例中，所记录的信息的哪些属性清楚地区分了TRACE级别而不是DEBUG级别的记录？
为什么这些信息必须通过日志基础结构吗？
将信息保留在日志日志中而不是仅使用
System.out.println有什么好处？为什么使用日志更好？而不是调试器？
在TRACE级别上进行日志记录的典型示例是什么？
有什么特别的收获？通过在TRACE级别而不是在示例中进行调试来进行记录？
为什么这些收益很重要？
相反：通过将其记录在TRACE而不是DEBUG上可以避免什么问题？
我还能如何解决这些问题？为什么在TRACE级别的日志记录比其他解决方案更好？
应该在生产代码中保留TRACE级别的日志语句吗？为什么？
但是考虑到它存在于大多数主要框架中，我想它对某些东西有用吗？那么... TRACE的作用是什么，它与DEBUG有何区别？
#1 楼
应该使用TRACE而不是DEBUG记录的信息的示例是什么？
如果我有经过一堆步骤的算法，则跟踪级别将打印信息关于每个步骤的最佳状态。像每个步骤的文字输入和输出之类的东西。
通常，跟踪将包括所有调试（就像debug包含所有警告和错误一样。）。
通过记录该信息可以解决什么特定问题？
您需要调试一些输出过多数据的东西，以便在针对特定对象进行调试时将其记录到特定构建之外。不关心错误或其他日志记录信息（因为跟踪信息的数量会掩盖它们）。在某些记录器中，您将仅将某个模块提升到跟踪级别。在这些示例中，已记录信息的属性是什么，这些属性清楚地区分了TRACE级别的记录，而不是TRACE级别的记录。一般而言，跟踪级别的日志记录无法持续运行，因为它会大大降低应用程序的性能，并且/或者创建大量的日志数据，从而无法持续运行。由于磁盘/带宽限制而无法持续。
调试级别的日志记录通常可以打开较长的时间，而不会导致应用程序无法使用。
为什么这些信息必须通过日志基础结构？
不必。某些框架具有单独的跟踪记录器。
由于跟踪记录器和普通记录器在写入磁盘/网络，错误处理，日志轮换等方面有类似的需求，因此通常最终会出现在日志中。 >
为什么为此使用日志而不是调试器会更好？
因为调试器可能无法连接到有问题的机器。您可能不甚了解，甚至不知道在哪里设置断点或单步执行代码。您可能无法在调试器中可靠地重现该错误，因此请使用日志“在发生时”捕获该错误。
但是它们只是名字。像其他任何标签一样，它们只是人们穿上东西的名字，通常对不同的人意味着不同的东西。而且标签本身并不如标签所指的肉味那么重要。
评论
“性能”方面确实可以帮助我理解。谢谢！
– Laurent Bourgault-Roy
2015年4月20日在19:45
我要补充一点，可以在断点调试器会干扰正确代码执行的地方使用跟踪，例如中断处理程序，计时器和紧密耦合的多线程代码。
– andy256
15年4月20日在22:31
@ andy256-以我的经验，跟踪级别的日志记录也会打乱此类工作。
– Telastyn
15年4月20日在22:42
@Telastyn是的，当然可以。多少取决于系统公差。工程师必须了解可用的工具，并为工作选择合适的工具。
– andy256
15年4月20日在22:50
#2 楼
请特别注意slf4j特别建议不要使用trace（http://slf4j.org/faq.html#trace）：简而言之，尽管我们仍然不鼓励使用TRACE level
因为存在替代方案，或者在很多情况下，由于人们一直在要求TRACE级别的日志请求是浪费的，因此我们
决定屈服于大众需求。
就个人而言，我的期望是对trace进行日志记录（例如，甚至包括诸如“在Y时刻输入带有参数A，B，C的输入函数MyFunc之类的东西）”。不利的一面是，这不仅令人难以置信的嘈杂，而且还容易引起磁盘空间问题。我希望在正常操作期间禁用此类日志记录。好处是，这可以为您提供类似于在附加调试器不太实用的情况下逐步执行程序时所获得的信息。
通常，我发现跟踪通常更有效比其他方法更努力。
评论
在极端情况下，跟踪级别的日志记录可以提供整个执行过程中程序完整状态的可再现，可逆日志（以数据库事务日志的形式）。那是在追踪所有东西，或者至少是正在追踪的所有东西:-)
–史蒂夫·杰索普（Steve Jessop）
2015年4月20日在21:49
#3 楼
调试级别通常是完全任意的，并且在语言，库和公司之间可以有所不同。，这就是我如何看待它们的使用方式：
TRACE：使用过用于显示逻辑级程序流。输入了功能？ “ if”语句选择主分支还是“ else”分支？那是追踪的候选人。换句话说，跟踪日志记录通常用于指定“您在这里”。这在可能记录错误或其他信息的其他记录语句的上下文中很有用。跟踪日志记录可以帮助您在代码中精确定位错误或其他级别记录的其他事件的位置。
调试：用于转储变量状态，特定的错误代码等。例如： Web服务可能返回错误代码809214，当应用程序告知用户“通信失败”时，可以记录该错误代码。想象一下，开发人员在错误发生很长时间之后就从用户系统接收日志，并且想知道“为什么会发生错误？”在调试级别记录日志是一件好事。另一个例子可能是如果错误始终在生产中发生，但很难重现，请在有问题的模块中调试记录某些变量或事件，以帮助告知开发人员错误发生时的程序状态，以帮助进行故障排除。
通常，可以将应用程序配置为以给定级别（或更高级别）登录。例如，跟踪通常是最低级别：在该级别进行日志记录所有内容。调试级别将省略跟踪，但包括高级（例如警告和错误）。
隔离日志级别的好处是控制记录的数量。对于复杂的应用程序，跟踪日志记录可能会记录大量数据，其中大部分在大多数情况下是无用的。最好只记录关键信息（可能是一些启动信息，然后是错误），除非有人试图确定导致错误的原因。此外，这通常仅在生产环境中有用，而没有调试器和其他开发工具。
对此没有实际限制，没有规则要求您必须记录某种方式。仅遵循某些库或应用程序可能会或可能不会的广泛约定。
#4 楼
这是我的经验法则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。您完全不必担心它将对生产机器产生什么影响，但是您现在在开发代码时就需要该信息。您是在说：“我不保证始终在生产中记录此信息是个好主意。” （正如其他人所说的那样），这些都是任意的；因此只需确保您的开发团队（和操作/监视团队-因为他们也是您的日志记录的用户）就某件事达成共识。
#5 楼
我认为Telastyn的出色答案可以归结为我的经验法则：DEBUG测井必须能够在生产中使用（但通常仍会关闭） TRACE日志记录应允许在生产中（特定的/简短的会话除外）不可行使用日志记录#6 楼
在TRACE级别上进行日志记录的典型示例是什么？
从一种方法进入/退出日志。这些日志可帮助您跟踪程序的流程，并在以下情况下非常有用：
程序突然崩溃-通过查看最后一行，您可以确切地知道崩溃的功能log
某些流氓功能通过吸收异常而静默失败
它们保证单独的TRACE级别，而不仅仅是使用DEBUG，因为为代码库中的每个方法启用ENTRY / EXIT日志将甚至在DEBUG上下文中也会生成大量无法正常运行的额外日志。
评论
有很多的 '？'在上述问题中。我强烈建议将问题缩小到可以完全回答的一个方面（而不是很多部分回答）。好吧，我并不是真正要求有关日志记录的一般信息。我只想了解为什么存在TRACE级别，以及何时使用它。
我同意：可能会有类似的问题，但这不是其中之一。
@gnat我检查了您标记为重复的问题，它在任何地方都无法解释TRACE的用例。我想礼貌地要求删除重复标记。 （除非我在您链接的问题中错过了它？）
@ s.d来自log4J 1.2文档，我在问题中添加了源代码。