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

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

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

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

在此之前，我已经构建了以下系统：

错误-表示出现了严重错误，特定线程/进程/序列无法继续。需要一些用户/管理员干预警告-有些事情不正确，但过程可以照常进行（例如，一组100个作业中的一个作业失败，但剩余的作业可以处理）

在我所构建的系统中，管理员都在接受指示，以应对错误。另一方面，我们将观察警告，并确定每种情况是否需要任何系统更改、重新配置等。

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

是->错误无->警告

错误是一种错误的东西，很明显是错误的，没有办法解决它，它需要被修复。

警告是一种模式的信号，这种模式可能是错误的，但也可能不是。

话虽如此，但我无法提出一个警告的好例子，这不是一个错误。我的意思是，如果您遇到了记录警告的麻烦，那么不妨解决根本问题。

然而，像“sql执行时间过长”这样的情况可能是一个警告，而“sql执行死锁”是一个错误，所以可能毕竟存在一些情况。

我一般同意以下约定：

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

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

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

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

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

国庆节，

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

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

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

HTH

我完全同意其他人的观点，并认为GrayWizardx说得最好。

我所能补充的是，这些级别通常对应于它们的字典定义，所以这并不难。如果有疑问，请像拼图一样对待它。对于您的特定项目，考虑您可能想要记录的所有内容。

现在，你能找出什么可能是致命的吗？你知道什么是致命的，不是吗？那么，你的清单上哪些项目是致命的。

好的，这是致命的问题，现在让我们看看错误。。。冲洗并重复。

在“致命”以下，或者可能是“错误”以下，我建议信息多总比信息少好，所以错误“向上”。不确定是信息还是警告？然后发出警告。

我确实认为，致命和错误应该是我们所有人都清楚的。其他的可能更模糊，但可以说，把它们弄对并不那么重要。

以下是一些示例：

致命-无法分配内存、数据库等-无法继续。

错误-没有回复消息、事务中止、无法保存文件等。

警告-资源分配达到X%（例如80%）-这表明您可能需要重新调整维度。

信息-用户登录/注销、新事务、文件装箱、新d/b字段或删除的字段。

内部数据结构的调试转储，任何带有文件名和行号的跟踪级别。跟踪-操作成功/失败，已更新d/b。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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日志记录指南。）

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

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

我建议只使用三个级别

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

我的两分钱关于致命和跟踪错误日志级别。

ERROR（错误）是指发生某些FAULT（异常）时。

致命实际上是双重故障：在处理异常时发生异常。

web服务很容易理解。

请求来了。事件记录为INFO系统检测到磁盘空间不足。事件记录为警告调用某个函数来处理请求。当处理被零除时。事件记录为ERROR调用Web服务的异常处理程序来处理除以零的操作。Web服务/框架将发送电子邮件，但无法发送，因为邮件服务现在处于脱机状态。第二个异常无法正常处理，因为Web服务的异常处理程序无法处理异常。调用了不同的异常处理程序。事件记录为致命

TRACE是我们可以跟踪函数入口/出口的时间。这与日志无关，因为此消息可以由某些调试器生成，而您的代码根本没有调用日志。因此，非来自应用程序的消息被标记为TRACE级别。例如，使用strace运行应用程序

因此，通常在程序中，您会进行DEBUG、INFO和WARN日志记录。只有当你正在编写一些web服务/框架时，你才会使用FATAL。当您调试应用程序时，您将从这种类型的软件获得TRACE日志记录。

这是一个古老的话题，但仍然相关。本周，我为同事们写了一篇关于它的小文章。出于这个目的，我还制作了这个备忘单，因为我在网上找不到。

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

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

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

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

从…起https://sematext.com/blog/slf4j-tutorial/:

TRACE–具有此级别的日志事件是最细粒度的，通常不需要，除非您需要完全了解应用程序中和所使用的第三方库中发生的情况。您可以期望TRACE日志记录级别非常详细。调试–与TRACE级别相比粒度更小，但仍比日常使用中需要的更多。DEBUG日志级别应用于深入诊断和故障排除所需的信息。INFO–表示发生了什么、应用程序处理了请求等的标准日志级别。使用INFO日志级别记录的信息应该是纯粹的信息，不定期查看这些信息不会导致丢失任何重要信息。警告–指示应用程序中发生意外事件的日志级别。例如，一个问题，或者一个可能会干扰其中一个进程但整个应用程序仍在运行的情况。错误–当应用程序遇到阻止一个或多个功能正常运行的问题时，应使用的日志级别。当其中一个支付系统不可用时，可以使用ERROR日志级别，但仍然可以选择在电子商务应用程序中检查购物篮，或者当您的社交媒体日志选项由于某种原因无法工作时。您还可以看到与异常相关的ERROR日志级别。

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

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