我建议采用Syslog严重级别：调试、信息、通知、警告、错误、严重、警报、紧急。看见http://en.wikipedia.org/wiki/Syslog#Severity_levels

它们应该为大多数用例提供足够的细粒度严重性级别，并被现有的日志解析器识别。当然，您可以根据应用程序的要求，自由地只实现一个子集，例如调试、错误、紧急情况。

让我们对已有多年的应用程序进行标准化，而不是为我们制作的每个不同应用程序制定自己的标准。一旦您开始聚合日志并尝试检测不同日志之间的模式，这将非常有用。

下面是“伐木工人”的清单。

Apache日志4j:§1，§2

致命：[v1.2:..]非常严重的错误事件，可能会导致应用程序中止。[v2.0:..]严重错误，将阻止应用程序继续运行。错误：[v1.2:..]可能仍然允许应用程序继续运行的错误事件。[v2.0:..]应用程序中的错误，可能可以恢复。警告：[v1.2:..]潜在的有害情况。[v2.0:..]事件可能导致错误。信息：[v1.2:..]在粗粒度级别突出显示应用程序进度的信息性消息。[v2.0:..]事件，仅供参考。调试：[v1.2:..]对调试应用程序最有用的细粒度信息事件。[v2.0:..]常规调试事件。跟踪：[v1.2:..]比DEBUG更细粒度的信息事件。[v2.0:..]细粒度调试消息，通常捕获通过应用程序的流。

Apache Httpd（和往常一样）喜欢过度使用：§

紧急情况：紧急情况–系统不可用。警觉的：必须立即采取行动[但系统仍然可用]。比容：关键条件[但无需立即采取行动]。套接字：无法获取套接字，正在退出子级错误：错误条件[但不重要]。“脚本头过早结束”警告：警告条件。[接近错误，但不是错误]通知：正常但显著的情况。httpd:捕获SIGBUS，试图在中转储核心信息：信息[和不可旋转]。[“服务器已运行x小时。”]调试：调试级消息[，即为调试而记录的消息）]。“正在打开配置文件…”痕迹1→ 痕迹6：跟踪消息[，即为跟踪而记录的消息]。“代理：FTP：控制连接完成”“proxy:CONNECT:向远程代理发送CONNECT请求”“openssl:握手：启动”“从缓冲SSL旅读取，模式0，17字节”“地图查找失败：map=rewriteitemap key=keyname”缓存查找失败，强制新的映射查找痕迹7→ 痕迹8：跟踪消息，转储大量数据“|0000:02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |”“|0000:02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |”

Apache commons日志记录：§

致命：导致提前终止的严重错误。期望这些在状态控制台上立即可见。错误：其他运行时错误或意外情况。期望这些在状态控制台上立即可见。警告：使用不推荐使用的API、API使用不当、“几乎”错误、其他不希望或意外但不一定“错误”的运行时情况。期望这些在状态控制台上立即可见。信息：有趣的运行时事件（启动/关闭）。期望这些在控制台上立即可见，所以要保守，尽量减少。调试：有关通过系统的流程的详细信息。期望这些仅写入日志。跟踪：更详细的信息。期望这些仅写入日志。

Apache commons记录企业使用的“最佳实践”，根据调试和信息跨越的界限来区分它们。

边界包括：

外部边界-预期异常。外部边界-意外异常。内部边界。重要内部边界。

（有关详细信息，请参阅commons日志记录指南。）

你想让系统管理员半夜起床吗？

是->错误无->警告

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

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

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

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

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

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

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

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

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

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

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

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