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

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

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

我一般同意以下约定：

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

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

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

是->错误无->警告

我建议只使用三个级别

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