错误是一种错误的东西，很明显是错误的，没有办法解决它，它需要被修复。

警告是一种模式的信号，这种模式可能是错误的，但也可能不是。

话虽如此，但我无法提出一个警告的好例子，这不是一个错误。我的意思是，如果您遇到了记录警告的麻烦，那么不妨解决根本问题。

然而，像“sql执行时间过长”这样的情况可能是一个警告，而“sql执行死锁”是一个错误，所以可能毕竟存在一些情况。

我建议只使用三个级别

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

我发现从查看日志文件的角度考虑严重性更有用。

致命/严重：应立即调查的整体应用程序或系统故障。是的，唤醒SysAdmin。因为我们更喜欢SysAdmins警报，并且休息良好，所以应该很少使用这种严重性。如果它每天都在发生，而这不是BFD，那么它就失去了意义。通常，致命错误在进程生命周期中只发生一次，因此如果日志文件与进程绑定，这通常是日志中的最后一条消息。

错误：肯定是一个应该调查的问题。SysAdmin应该被自动通知，但不需要被拖下床。通过过滤日志以查看错误和以上内容，您可以获得错误频率的概述，并可以快速识别可能导致额外错误级联的初始故障。跟踪错误率与应用程序使用率之间的关系可以得出有用的质量指标，如MTBF，可用于评估总体质量。例如，这个度量可能有助于在发布之前决定是否需要另一个测试周期。

警告：这可能是问题，也可能不是。例如，预期的瞬时环境条件（如网络或数据库连接短暂中断）应记录为警告，而不是错误。查看经过筛选的日志以仅显示警告和错误，可以快速了解后续错误的根本原因的早期提示。警告应谨慎使用，以免变得毫无意义。例如，失去网络访问应该是服务器应用程序中的一个警告，甚至是一个错误，但可能只是为偶尔断开连接的笔记本电脑用户设计的桌面应用程序的一个信息。

信息：这是在正常情况下应记录的重要信息，如成功初始化、服务启动和停止或重要事务的成功完成。查看显示“信息”及以上内容的日志应该可以快速概述流程中的主要状态更改，为理解任何警告或错误提供顶级上下文。不要有太多信息消息。相对于跟踪，我们通常有<5%的信息消息。

跟踪：跟踪是迄今为止最常用的严重性，应该提供上下文以了解导致错误和警告的步骤。拥有正确的跟踪消息密度可以使软件更易于维护，但需要一定的努力，因为随着程序的发展，单个跟踪语句的价值可能会随着时间的推移而变化。实现这一点的最佳方法是让开发团队养成定期查看日志的习惯，作为解决客户报告问题的标准部分。鼓励团队删除不再提供有用上下文的跟踪消息，并在需要时添加消息以了解后续消息的上下文。例如，记录用户输入（如更改显示或选项卡）通常很有用。

调试：我们考虑Debug＜Trace。区别在于调试消息是从发布版本编译出来的。也就是说，我们不鼓励使用调试消息。允许调试消息往往会导致越来越多的调试消息被添加，而从未删除过。随着时间的推移，这使得日志文件几乎无用，因为它太难从噪声中过滤信号。这导致开发人员不使用继续死亡螺旋的日志。相反，不断修剪Trace消息会鼓励开发人员使用这些消息，从而形成良性循环。此外，这消除了由于调试代码中所需的副作用而引入bug的可能性，这些副作用未包含在发布版本中。是的，我知道这不应该发生在好的代码中，但安全总比抱歉好。

根据RFC 5424，系统日志协议（IETF）-第10页：

每个消息优先级也有一个十进制严重性级别指示符。下表中描述了这些参数及其数值价值观严重性值必须介于0到7之间（含0到7）。数值严重性密码0紧急情况：系统不可用1警报：必须立即采取行动2临界：临界条件3错误：错误条件4警告：警告条件5注意：正常但重要的情况6信息：信息性消息7调试：调试级别消息表2。Syslog消息严重性

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

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

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

正如其他人所说，错误是问题；警告是潜在的问题。

在开发中，我经常使用警告，在警告中，我可能会放置相当于断言失败，但应用程序可以继续工作；这使我能够发现这个案子是否真的发生过，或者这是我的想象。

但是的，它归结到恢复性和现实性方面。如果你能恢复，那可能是一个警告；如果它导致某个东西实际失败，那就是一个错误。