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

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

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

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

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

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

我建议只使用三个级别

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

微软如何在其新的准标准Microsoft.Extension.Logging中定义不同的LogLevel值非常有趣（重点是我的）：

批评的描述不可恢复的应用程序或系统崩溃或需要立即关注的灾难性故障。错误当前执行流停止时突出显示的日志失败。这些应指示当前活动中的故障，而不是应用程序范围内的故障。警告突出显示应用程序中异常或意外事件的日志但不会导致应用程序执行停止。信息跟踪应用程序一般流程的日志。这些日志应该具有长期价值。调试开发期间用于交互式调查的日志。这些日志应主要包含对调试有用的信息并且没有长期价值。查出包含最详细消息的日志。这些消息可能包含敏感应用程序数据。这些消息被禁用默认设置，在生产环境中永远不应启用。

国庆节，

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

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

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

HTH