根据RFC 5424，系统日志协议（IETF）-第10页：

每个消息优先级也有一个十进制严重性级别指示符。下表中描述了这些参数及其数值价值观严重性值必须介于0到7之间（含0到7）。数值严重性密码0紧急情况：系统不可用1警报：必须立即采取行动2临界：临界条件3错误：错误条件4警告：警告条件5注意：正常但重要的情况6信息：信息性消息7调试：调试级别消息表2。Syslog消息严重性

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

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

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

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

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

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

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

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

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

顺便说一句，我非常喜欢捕捉一切，然后过滤信息。

如果您在“警告”级别捕获，并希望获得与警告相关的一些调试信息，但无法重新创建警告，会发生什么情况？

捕获所有内容并稍后过滤！

即使对于嵌入式软件，这也是正确的，除非你发现你的处理器跟不上，在这种情况下，你可能需要重新设计你的跟踪以使其更高效，或者跟踪干扰了时间（你可能会考虑在一个更强大的处理器上调试，但这会带来另一种蠕虫）。

捕获所有内容并稍后过滤！！

（顺便说一句，捕获一切也很好，因为它让您可以开发工具来做更多的工作，而不仅仅是显示调试跟踪（我从中绘制了消息序列图，以及内存使用情况的直方图。它还为您提供了一个基础，以便在将来发生错误时进行比较（保留所有日志，无论是通过还是失败，并确保在日志文件中包含内部版本号））。

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

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

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

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

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

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

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