塔科·扬·奥辛加的回答非常好，而且非常实用。

我同意他的观点，尽管有些不同。

在Python上，只有5个“命名”日志级别，所以我是这样使用它们的：

调试——对故障排除很重要的信息，通常在正常的日常操作中被抑制信息——日常操作，作为程序按设计执行功能的“证明”警告——超出名义但可恢复的情况，*或*遇到可能导致未来问题的事情错误——发生了一些需要程序执行恢复的事情，但恢复成功。不过，程序可能没有处于最初预期的状态，因此程序用户需要进行调整关键——发生了无法挽回的事情，程序可能需要终止，以免每个人都生活在罪恶的状态中

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

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

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

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

我建议只使用三个级别

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

我的两分钱关于致命和跟踪错误日志级别。

ERROR（错误）是指发生某些FAULT（异常）时。

致命实际上是双重故障：在处理异常时发生异常。

web服务很容易理解。

请求来了。事件记录为INFO系统检测到磁盘空间不足。事件记录为警告调用某个函数来处理请求。当处理被零除时。事件记录为ERROR调用Web服务的异常处理程序来处理除以零的操作。Web服务/框架将发送电子邮件，但无法发送，因为邮件服务现在处于脱机状态。第二个异常无法正常处理，因为Web服务的异常处理程序无法处理异常。调用了不同的异常处理程序。事件记录为致命

TRACE是我们可以跟踪函数入口/出口的时间。这与日志无关，因为此消息可以由某些调试器生成，而您的代码根本没有调用日志。因此，非来自应用程序的消息被标记为TRACE级别。例如，使用strace运行应用程序

因此，通常在程序中，您会进行DEBUG、INFO和WARN日志记录。只有当你正在编写一些web服务/框架时，你才会使用FATAL。当您调试应用程序时，您将从这种类型的软件获得TRACE日志记录。

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

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

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

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

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

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

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