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

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

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

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

我建议只使用三个级别

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

国庆节，

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

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

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

HTH

可以从中恢复的警告。错误你不能。这是我的启发，其他人可能有其他想法。

例如，假设您在应用程序中输入/导入名称“Angela Müller”（注意u上的元音变音）。您的代码/数据库可能仅为英文（尽管它可能不应该在这个时代），因此可能会警告所有“不寻常”字符都已转换为普通英文字符。

与之形成对比的是，尝试将信息写入数据库，并连续60秒返回网络关闭消息。这与其说是警告，不如说是错误。

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

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

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

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

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

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

以下是一些示例：

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

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

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

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

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