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

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

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

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

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

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

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

我认为，对于应用程序级别的日志记录来说，SYSLOG级别NOTICE和ALERT/EEMERGENCY在很大程度上是多余的-而CRITICAL/ALERT/EEMGENCY对于可能触发不同操作和通知的操作员来说可能是有用的警报级别，但对于应用程序管理员来说，这与FATAL相同。我只是无法充分区分被通知还是一些信息。如果信息不值得注意，那么它就不是真正的信息：）

我最喜欢Jay Cincotta的解释-跟踪代码的执行在技术支持中非常有用，应该鼓励将跟踪语句自由地放入代码中-尤其是与动态过滤机制结合使用，以记录来自特定应用程序组件的跟踪消息。然而，对我来说，DEBUG级别表明我们仍在弄清楚发生了什么——我认为DEBUG级输出只是一个开发选项，而不是应该在生产日志中显示的内容。

然而，对于OPERATIONAL消息，当我戴着系统管理员和技术支持甚至开发人员的帽子时，我希望在错误日志中看到一个日志级别。我使用它来记录时间戳、调用的操作类型、提供的参数、可能的（唯一）任务标识符和任务完成情况。例如，当一个独立的任务被启动时，它就被使用了，这是一个来自大型长时间运行的应用程序的真正调用。这是我希望始终记录的事情，无论是否有任何问题，所以我认为OPER级别高于致命级别，因此您只能通过进入完全静音模式来关闭它。它不仅仅是INFO日志数据，这是一个日志级别，经常被滥用，用于发送没有任何历史价值的小操作消息。

根据具体情况，这些信息可以被定向到单独的调用日志，或者可以通过从记录更多信息的大型日志中过滤出来获得。但是，作为历史信息，它总是需要知道正在做什么，而不是下降到AUDIT级别，这是另一个完全独立的日志级别，与故障或系统操作无关，并不真正符合上述级别（因为它需要自己的控制开关，而不是严重性分类），而且它肯定需要自己的独立日志文件。

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

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

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

我一般同意以下约定：

跟踪-只有当我“跟踪”代码并试图找到函数的某一部分时。调试-对开发人员（IT、系统管理员等）以外的人有诊断帮助的信息。信息-要记录的一般有用信息（服务启动/停止、配置假设等）。我想随时提供信息，但在正常情况下通常不关心。这是我的开箱即用配置级别。警告-任何可能导致应用程序异常的情况，但我会自动恢复。（例如从主服务器切换到备份服务器、重试操作、丢失辅助数据等）错误-任何对操作（而不是服务或应用程序）致命的错误（无法打开所需的文件、丢失的数据等）。这些错误将迫使用户（管理员或直接用户）进行干预。这些通常是为不正确的连接字符串、丢失的服务等保留的（在我的应用程序中）。致命-强制关闭服务或应用程序以防止数据丢失（或进一步数据丢失）的任何错误。我只为最令人发指的错误和保证存在数据损坏或丢失的情况保留这些。

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

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

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