顺便说一句，我非常喜欢捕捉一切，然后过滤信息。

如果您在“警告”级别捕获，并希望获得与警告相关的一些调试信息，但无法重新创建警告，会发生什么情况？

捕获所有内容并稍后过滤！

即使对于嵌入式软件，这也是正确的，除非你发现你的处理器跟不上，在这种情况下，你可能需要重新设计你的跟踪以使其更高效，或者跟踪干扰了时间（你可能会考虑在一个更强大的处理器上调试，但这会带来另一种蠕虫）。

捕获所有内容并稍后过滤！！

（顺便说一句，捕获一切也很好，因为它让您可以开发工具来做更多的工作，而不仅仅是显示调试跟踪（我从中绘制了消息序列图，以及内存使用情况的直方图。它还为您提供了一个基础，以便在将来发生错误时进行比较（保留所有日志，无论是通过还是失败，并确保在日志文件中包含内部版本号））。

我一般同意以下约定：

跟踪-只有当我“跟踪”代码并试图找到函数的某一部分时。调试-对开发人员（IT、系统管理员等）以外的人有诊断帮助的信息。信息-要记录的一般有用信息（服务启动/停止、配置假设等）。我想随时提供信息，但在正常情况下通常不关心。这是我的开箱即用配置级别。警告-任何可能导致应用程序异常的情况，但我会自动恢复。（例如从主服务器切换到备份服务器、重试操作、丢失辅助数据等）错误-任何对操作（而不是服务或应用程序）致命的错误（无法打开所需的文件、丢失的数据等）。这些错误将迫使用户（管理员或直接用户）进行干预。这些通常是为不正确的连接字符串、丢失的服务等保留的（在我的应用程序中）。致命-强制关闭服务或应用程序以防止数据丢失（或进一步数据丢失）的任何错误。我只为最令人发指的错误和保证存在数据损坏或丢失的情况保留这些。

从…起https://sematext.com/blog/slf4j-tutorial/:

TRACE–具有此级别的日志事件是最细粒度的，通常不需要，除非您需要完全了解应用程序中和所使用的第三方库中发生的情况。您可以期望TRACE日志记录级别非常详细。调试–与TRACE级别相比粒度更小，但仍比日常使用中需要的更多。DEBUG日志级别应用于深入诊断和故障排除所需的信息。INFO–表示发生了什么、应用程序处理了请求等的标准日志级别。使用INFO日志级别记录的信息应该是纯粹的信息，不定期查看这些信息不会导致丢失任何重要信息。警告–指示应用程序中发生意外事件的日志级别。例如，一个问题，或者一个可能会干扰其中一个进程但整个应用程序仍在运行的情况。错误–当应用程序遇到阻止一个或多个功能正常运行的问题时，应使用的日志级别。当其中一个支付系统不可用时，可以使用ERROR日志级别，但仍然可以选择在电子商务应用程序中检查购物篮，或者当您的社交媒体日志选项由于某种原因无法工作时。您还可以看到与异常相关的ERROR日志级别。

我完全同意其他人的观点，并认为GrayWizardx说得最好。

我所能补充的是，这些级别通常对应于它们的字典定义，所以这并不难。如果有疑问，请像拼图一样对待它。对于您的特定项目，考虑您可能想要记录的所有内容。

现在，你能找出什么可能是致命的吗？你知道什么是致命的，不是吗？那么，你的清单上哪些项目是致命的。

好的，这是致命的问题，现在让我们看看错误。。。冲洗并重复。

在“致命”以下，或者可能是“错误”以下，我建议信息多总比信息少好，所以错误“向上”。不确定是信息还是警告？然后发出警告。

我确实认为，致命和错误应该是我们所有人都清楚的。其他的可能更模糊，但可以说，把它们弄对并不那么重要。

以下是一些示例：

致命-无法分配内存、数据库等-无法继续。

错误-没有回复消息、事务中止、无法保存文件等。

警告-资源分配达到X%（例如80%）-这表明您可能需要重新调整维度。

信息-用户登录/注销、新事务、文件装箱、新d/b字段或删除的字段。

内部数据结构的调试转储，任何带有文件名和行号的跟踪级别。跟踪-操作成功/失败，已更新d/b。

我一直在考虑警告第一个日志级别，这肯定意味着存在问题（例如，可能配置文件不在应该的位置，我们将不得不使用默认设置运行）。对我来说，一个错误意味着软件的主要目标现在不可能实现，我们将尝试彻底关闭。

在此之前，我已经构建了以下系统：

错误-表示出现了严重错误，特定线程/进程/序列无法继续。需要一些用户/管理员干预警告-有些事情不正确，但过程可以照常进行（例如，一组100个作业中的一个作业失败，但剩余的作业可以处理）

在我所构建的系统中，管理员都在接受指示，以应对错误。另一方面，我们将观察警告，并确定每种情况是否需要任何系统更改、重新配置等。