何时使用不同的日志级别
有不同的方法来记录消息，按死亡顺序排列：
致命错误警告信息调试跟踪
我如何决定何时使用哪个？
什么是一个好的启发式使用？
notice 有人不会...
notice 很可能会丢失，因为一些流行的日志记录服务（如 log4j）不使用它。
我通常订阅以下约定：
跟踪 - 只有当我要“跟踪”代码并试图专门找到函数的一部分时。
调试 - 不仅对开发人员（IT、系统管理员等）有诊断帮助的信息。
信息 - 一般有用的记录信息（服务启动/停止、配置假设等）。信息我希望始终可用，但在正常情况下通常不关心。这是我开箱即用的配置级别。
警告 - 任何可能导致应用程序异常但我正在自动恢复的东西。 （如从主服务器切换到备用服务器、重试操作、丢失辅助数据等）
错误 - 任何对操作致命的错误，但对服务或应用程序不致命（无法打开所需文件、丢失数据等）。这些错误将强制用户（管理员或直接用户）干预。这些通常保留（在我的应用程序中）用于不正确的连接字符串、缺少服务等。
致命 - 任何强制关闭服务或应用程序以防止数据丢失（或进一步数据丢失）的错误。我仅将这些保留用于最令人发指的错误和保证数据损坏或丢失的情况。
您是否希望该消息让系统管理员在半夜起床？
是 -> 错误
不 -> 警告
FATAL 是系统管理员醒来，认为他没有为此支付足够的费用，然后重新入睡。
我发现从查看日志文件的角度考虑严重性更有帮助。
致命/严重：应立即调查的整体应用程序或系统故障。是的，唤醒系统管理员。由于我们更喜欢我们的 SysAdmins 警报并且休息良好，因此应该很少使用这种严重性。如果它每天都在发生并且这不是 BFD，那么它就失去了意义。通常，致命错误在进程生命周期中只发生一次，因此如果日志文件与进程绑定，这通常是日志中的最后一条消息。
错误：绝对是一个应该调查的问题。应该自动通知系统管理员，但不需要被拖下床。通过过滤日志以查看错误及以上内容，您可以获得错误频率的概览，并可以快速识别可能导致一连串其他错误的启动故障。跟踪错误率与应用程序使用情况可以产生有用的质量指标，例如 MTBF，可用于评估整体质量。例如，该指标可能有助于决定在发布之前是否需要另一个 beta 测试周期。
警告：这可能是问题，也可能不是。例如，预期的瞬态环境条件（例如网络或数据库连接的短暂丢失）应记录为警告，而不是错误。查看过滤后仅显示警告和错误的日志可以快速洞察后续错误根本原因的早期提示。警告应谨慎使用，以免它们变得毫无意义。例如，失去网络访问权限应该是服务器应用程序中的警告甚至错误，但可能只是为偶尔断开连接的笔记本电脑用户设计的桌面应用程序中的信息。
信息：这是在正常情况下应记录的重要信息，例如成功初始化、服务启动和停止或重要事务的成功完成。查看显示 Info 及以上内容的日志应该可以快速概述过程中的主要状态变化，从而提供顶级上下文以了解同时发生的任何警告或错误。不要有太多的信息消息。我们通常有 < 5% 的 Info 消息相对于 Trace。
跟踪：跟踪是迄今为止最常用的严重性，应提供上下文以了解导致错误和警告的步骤。拥有正确密度的 Trace 消息可以使软件更易于维护，但需要一些努力，因为随着程序的发展，单个 Trace 语句的值可能会随着时间而变化。实现这一目标的最佳方法是让开发团队养成定期查看日志的习惯，将其作为解决客户报告问题的标准部分。鼓励团队删除不再提供有用上下文的 Trace 消息，并在需要的地方添加消息以了解后续消息的上下文。例如，记录用户输入（例如更改显示或选项卡）通常很有帮助。
Debug：我们认为 Debug < Trace。区别在于 Debug 消息是从 Release 版本中编译出来的。也就是说，我们不鼓励使用调试消息。允许 Debug 消息往往会导致添加越来越多的 Debug 消息，但从未删除过。随着时间的推移，这使得日志文件几乎毫无用处，因为从噪声中过滤信号太难了。这导致开发人员不使用继续死亡螺旋的日志。相比之下，不断修剪 Trace 消息会鼓励开发人员使用它们，从而形成良性循环。此外，这消除了由于调试代码中未包含在发布版本中所需的副作用而引入错误的可能性。是的，我知道这不应该发生在好的代码中，但更安全的是抱歉。
这是一个古老的话题，但仍然相关。本周，我为我的同事写了一篇关于它的小文章。为此，我还创建了这个备忘单，因为我在网上找不到任何内容。
https://i.stack.imgur.com/z5Fim.png
这是“记录器”拥有的列表。
FATAL: [v1.2: ..] 非常严重的错误事件，可能会导致应用程序中止。 [v2.0: ..] 严重错误将阻止应用程序继续。错误：[v1.2: ..] 可能仍允许应用程序继续运行的错误事件。 [v2.0: ..] 应用程序中的错误，可能可以恢复。警告：[v1.2: ..] 可能有害的情况。 [v2.0: ..] 可能导致错误的事件 [原文如此]。 INFO：[v1.2: ..] 信息性消息，在粗粒度级别突出显示应用程序的进度。 [v2.0: ..] 事件仅供参考。调试：[v1.2: ..] 对调试应用程序最有用的细粒度信息事件。 [v2.0: ..] 一般调试事件。 TRACE：[v1.2: ..] 比 DEBUG 更细粒度的信息事件。 [v2.0: ..] 细粒度调试消息，通常捕获通过应用程序的流。
Apache Httpd（像往常一样）喜欢大材小用：§
emerg：紧急情况——系统无法使用。警告：必须立即采取行动[但系统仍然可用]。 crit：关键条件[但无需立即采取行动]。 “套接字：无法获取套接字，正在退出子”错误：错误条件 [但不严重]。 “脚本头过早结束”警告：警告条件。 [接近错误，但不是错误] 注意：正常但显着 [显着] 情况。 “httpd：捕获 SIGBUS，试图将核心转储到 ...” 信息：信息性 [和不值得注意的]。 [“服务器已运行 x 小时。”] 调试：调试级消息 [，即为调试而记录的消息）]。 “打开配置文件...” trace1 → trace6：跟踪消息[，即为跟踪而记录的消息]。 “代理：FTP：控制连接完成”“代理：CONNECT：向远程代理发送 CONNECT 请求”“openssl：握手：开始”“从缓冲 SSL 旅读取，模式 0，17 字节”“地图查找失败：map= rewritemap key=keyname”“缓存查找失败，强制新映射查找”trace7 → trace8：跟踪消息，转储大量数据“| 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 公共日志记录：§
致命的：导致提前终止的严重错误。期望这些在状态控制台上立即可见。 error：其他运行时错误或意外情况。期望这些在状态控制台上立即可见。警告：使用已弃用的 API、API 使用不当、“几乎”错误、其他不希望或意外但不一定“错误”的运行时情况。期望这些在状态控制台上立即可见。 info：有趣的运行时事件（启动/关闭）。期望这些在控制台上立即可见，所以要保守并保持在最低限度。调试：有关通过系统的流量的详细信息。期望这些仅写入日志。跟踪：更详细的信息。期望这些仅写入日志。
用于企业使用的 Apache 公共日志记录“最佳实践”根据它们跨越的边界类型来区分调试和信息。
边界包括：
外部边界 - 预期的例外。
外部边界 - 意外异常。
内部边界。
重要的内部边界。
（有关这方面的更多信息，请参阅 commons-logging guide。）
如果您可以从问题中恢复过来，那么这是一个警告。如果它阻止继续执行，那么这是一个错误。
我建议采用 Syslog 严重级别：DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY。
请参阅 http://en.wikipedia.org/wiki/Syslog#Severity_levels
它们应该为大多数用例提供足够细粒度的严重级别，并被现有的日志解析器识别。当然，您可以自由地只实现一个子集，例如 DEBUG, ERROR, EMERGENCY，具体取决于您的应用程序的要求。
让我们对已经存在了很长时间的东西进行标准化，而不是为我们制作的每个不同的应用程序制定我们自己的标准。一旦您开始聚合日志并尝试检测不同日志的模式，它真的很有帮助。
DEBUG、INFO、WARNING 和 ERROR 开始。开发人员应该看到所有级别。系统管理员最多 INFO，并且最终用户可以看到警告和错误但前提是有一个框架来提醒他们。
DEBUG 和 TRACE 一样，供开发人员控制粒度。并且 ERROR 扩展到其他级别，如 CRITICAL、ALERT、EMERGENCY，以区分错误的严重性并根据严重性确定操作。
您可以从中恢复的警告。你不能犯的错误。这是我的启发式，其他人可能有其他想法。
例如，假设您在应用程序中输入/导入名称 "Angela Müller"（注意 u 上的变音符号）。您的代码/数据库可能只有英文（尽管它可能不应该在这个时代出现），因此可能会警告所有“不寻常”字符都已转换为常规英文字符。
相比之下，尝试将该信息写入数据库并连续 60 秒返回网络故障消息。这更像是一个错误而不是一个警告。
正如其他人所说，错误就是问题。警告是潜在的问题。
在开发中，我经常使用警告，我可能会放置相当于断言失败但应用程序可以继续工作的地方；这使我能够查明这种情况是否真的发生过，或者这是否是我的想象。
但是，是的，它归结为可恢复性和现实性方面。如果你能恢复，这可能是一个警告；如果它导致某些事情实际上失败，那就是一个错误。
来自 RFC 5424，Syslog Protocol (IETF) - 第 10 页：
每个消息优先级也有一个十进制严重级别指示器。下表对其数值进行了描述。严重性值必须在 0 到 7 的范围内。数字严重性代码 0 紧急：系统不可用 1 警报：必须立即采取措施 2 严重：严重情况 3 错误：错误情况 4 警告：警告情况 5 通知：正常但重要的情况 6 信息：信息性消息 7 调试：调试级别消息 表 2. Syslog 消息严重性
Taco Jan Osinga's answer 非常好，而且非常实用，可以启动。
我部分同意他的观点，尽管有一些变化。
在 Python 上，有 only 5 "named" logging levels，所以我是这样使用它们的：
DEBUG——对故障排除很重要的信息，通常在正常的日常操作中被抑制
信息——日常操作作为程序正在按设计执行其功能的“证据”
警告 - 超出名义但可恢复的情况，*或*遇到可能导致未来问题的事情
错误 - 发生了需要程序进行恢复的事情，但恢复是成功的。但是，程序可能不会处于最初预期的状态，因此程序的用户需要适应
CRITICAL - 发生了无法恢复的事情，程序可能需要终止，以免每个人都生活在罪恶状态
我完全同意其他人的观点，并认为 GrayWizardx 说得最好。
我可以补充的是，这些级别通常对应于它们的字典定义，所以它不会那么难。如有疑问，请将其视为谜题。对于您的特定项目，请考虑您可能想要记录的所有内容。
现在，你能弄清楚什么可能是致命的吗？你知道什么是致命的，不是吗？所以，你清单上的哪些项目是致命的。
好的，这是致命的处理，现在让我们看看错误......冲洗并重复。
在致命或错误之下，我建议更多的信息总是比更少的信息好，所以“向上”犯错。不确定是信息还是警告？然后将其作为警告。
我确实认为我们所有人都应该清楚致命和错误。其他的可能更模糊，但可以说让它们正确并不重要。
这里有些例子：
致命 - 无法分配内存、数据库等 - 无法继续。
错误 - 没有回复消息、交易中止、无法保存文件等。
警告 - 资源分配达到 X%（比如 80%） - 这表明您可能想要重新调整您的.
信息 - 用户登录/注销、新事务、文件箱、新 d/b 字段或已删除字段。
调试 - 内部数据结构转储，带有文件名和行号的任何跟踪级别。跟踪 - 操作成功/失败，已更新 d/b。
我认为 SYSLOG 级别 NOTICE 和 ALERT/EMERGENCY 对于应用程序级别的日志记录在很大程度上是多余的 - 而 CRITICAL/ALERT/EMERGENCY 对于可能触发不同操作和通知的操作员来说可能是有用的警报级别，对于应用程序管理员来说，这都是一样的致命的。而且我只是无法充分区分是收到通知还是某些信息。如果信息不值得注意，那不是真正的信息:)
我最喜欢 Jay Cincotta 的解释 - 跟踪代码的执行在技术支持中非常有用，应该鼓励将跟踪语句自由地放入代码中 - 特别是结合用于记录来自特定应用程序组件的跟踪消息的动态过滤机制。然而，对我来说，调试级别表明我们仍在弄清楚发生了什么 - 我将调试级别输出视为仅用于开发的选项，而不是应该出现在生产日志中的东西。
然而，当我戴着系统管理员的帽子时，我喜欢在错误日志中看到一个日志级别，就像技术支持，甚至开发人员的帽子一样：OPER，用于操作消息。我用它来记录时间戳、调用的操作类型、提供的参数、可能的（唯一）任务标识符和任务完成。当一个独立的任务被触发时使用它，这是从更大的长时间运行的应用程序中真正调用的东西。这是我希望始终记录的那种东西，无论是否出现任何问题，所以我认为 OPER 的级别高于 FATAL，因此您只能通过完全静音模式将其关闭。它不仅仅是 INFO 日志数据 - 一个日志级别经常被滥用，用于发送垃圾日志，其中包含没有任何历史价值的次要操作消息。
视情况而定，此信息可能会被定向到单独的调用日志，或者可以通过将其从记录更多信息的大型日志中过滤出来来获得。但是，作为历史信息，始终需要知道正在执行的操作 - 无需下降到 AUDIT 级别，另一个完全独立的日志级别与故障或系统操作无关，并不真正适合上述级别（因为它需要自己的控制开关，而不是严重性分类）并且肯定需要自己的单独日志文件。
天，
作为这个问题的必然结果，传达您对日志级别的解释，并确保项目中的所有人都对级别的解释保持一致。
看到种类繁多的日志消息的严重性和所选日志级别不一致是很痛苦的。
如果可能，请提供不同日志记录级别的示例。并且要在消息中记录的信息保持一致。
高温高压
关于 FATAL 和 TRACE 错误日志级别的两分钱。
ERROR 是发生某些 FAULT（异常）的时间。
FATAL实际上是DOUBLE FAULT：在处理异常时发生异常。
Web服务很容易理解。
请求来。事件被记录为 INFO 系统检测到磁盘空间不足。事件被记录为 WARN 调用某些函数来处理请求。在处理除以零时发生。事件被记录为 ERROR Web 服务的异常处理程序被调用以处理除以零。 Web 服务/框架将发送电子邮件，但它不能因为邮件服务现在离线。这第二个异常无法正常处理，因为 Web 服务的异常处理程序无法处理异常。调用了不同的异常处理程序。事件被记录为 FATAL
TRACE 是我们可以跟踪函数进入/退出的时间。这与记录无关，因为此消息可以由某些调试器生成，并且您的代码根本没有调用 log。因此，不是来自您的应用程序的消息被标记为 TRACE 级别。例如，您使用 strace 运行您的应用程序
因此，通常在您的程序中执行 DEBUG、INFO 和 WARN 日志记录。只有当您编写一些网络服务/框架时，您才会使用 FATAL。当您调试应用程序时，您将从此类软件中获得 TRACE 日志记录。
错误是错误的，完全错误的，无法解决，需要修复。
警告是一种可能是错误的模式的标志，但也可能不是。
话虽如此，我还是想不出一个很好的例子来说明不是错误的警告。我的意思是，如果您不小心记录警告，您不妨解决根本问题。
但是，“sql 执行时间太长”之类的可能是警告，而“sql 执行死锁”是错误，所以也许毕竟有一些情况。
varchar 中插入比定义更多的字符，它会警告您该值已被截断，但仍会插入它。但是一个人的警告可能是另一个人的错误：在我的情况下，这是一个错误；这意味着我通过定义与数据库不协调的长度在验证代码中出错。如果另一个数据库引擎认为这是一个错误，我也不会感到非常惊讶，而且我没有真正的权利感到愤慨，毕竟这是错误的。
我一直认为警告第一个日志级别肯定意味着存在问题（例如，配置文件可能不在它应该在的位置，我们将不得不使用默认设置运行）。对我来说，错误意味着软件的主要目标现在不可能实现，我们将尝试彻底关闭。
在此之前我已经构建了系统，使用以下内容：
错误 - 表示出现严重错误并且特定线程/进程/序列无法继续。需要一些用户/管理员干预 警告 - 有问题，但该过程可以像以前一样继续（例如，一组 100 个作业中的一个作业失败，但可以处理其余作业）
在我建立的系统中，管理员被指示对错误做出反应。另一方面，我们将观察警告并确定每种情况是否需要进行任何系统更改、重新配置等。
顺便说一句，我非常喜欢捕获所有内容并稍后过滤信息。
如果您在警告级别捕获并想要一些与警告相关的调试信息，但无法重新创建警告，会发生什么？
捕获所有内容并稍后过滤！
即使对于嵌入式软件也是如此，除非您发现您的处理器跟不上，在这种情况下，您可能需要重新设计跟踪以使其更高效，或者跟踪干扰时序（您可能会考虑在一个更强大的处理器，但这会打开一大堆蠕虫）。
捕获所有内容并稍后过滤！！
（顺便说一句，捕获一切也很好，因为它可以让您开发工具来做更多的事情，而不仅仅是显示调试跟踪（我从我的绘制消息序列图和内存使用情况的直方图。如果出现问题，它还为您提供了比较的基础未来（保留所有日志，无论是通过还是失败，并确保在日志文件中包含内部版本号））。
https://i.stack.imgur.com/76qHu.png
希望对那些正在寻找更详细答案的人有所帮助。
我建议只使用三个级别
致命 - 这会破坏应用程序。信息 - 信息调试 - 不太重要的信息
Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).。 Logger.Debug 仅供开发人员追踪生产中非常讨厌的问题，例如If you want to print the value of a variable at any given point inside a for loop against a condition