我建议只使用三个级别

致命-这会破坏应用程序。信息-信息调试-不太重要的信息

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

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

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

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

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

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

如果你能从问题中恢复过来，那就是一个警告。如果它阻止了继续执行，那就是一个错误。

国庆节，

作为这个问题的必然结果，沟通您对日志级别的解释，并确保项目中的所有人都对级别的解释保持一致。

看到各种各样的日志消息，其中的严重性和所选日志级别不一致，这很痛苦。

如果可能，请提供不同日志记录级别的示例。并且要在消息中记录的信息保持一致。

HTH

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

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

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

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

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

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

以下是一些示例：

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

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

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

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

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

微软如何在其新的准标准Microsoft.Extension.Logging中定义不同的LogLevel值非常有趣（重点是我的）：

批评的描述不可恢复的应用程序或系统崩溃或需要立即关注的灾难性故障。错误当前执行流停止时突出显示的日志失败。这些应指示当前活动中的故障，而不是应用程序范围内的故障。警告突出显示应用程序中异常或意外事件的日志但不会导致应用程序执行停止。信息跟踪应用程序一般流程的日志。这些日志应该具有长期价值。调试开发期间用于交互式调查的日志。这些日志应主要包含对调试有用的信息并且没有长期价值。查出包含最详细消息的日志。这些消息可能包含敏感应用程序数据。这些消息被禁用默认设置，在生产环境中永远不应启用。