何时使用不同的日志级别

有不同的方法来记录消息，按死亡顺序：

  1. FATAL

  2. ERROR

  3. WARN

  4. INFO

  5. DEBUG

  6. TRACE

我如何决定何时使用哪个？

什么是好的启发式使用？

540278 次浏览
小开

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

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

相比之下，尝试将该信息写入数据库并连续60秒返回网络故障消息。这与其说是警告，不如说是错误。

小开

如果您可以从问题中恢复，那么它就是一个警告。如果它阻止继续执行，那么它就是一个错误。

小开

我之前构建的系统使用以下内容：

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

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

小开

您希望该消息在半夜让系统管理员起床吗？

  • 是->错误
  • 否->警告
小开

错误是错误的，明显的错误，没有办法绕过它，它需要修复。

警告是模式的标志，可能是错误的，但也可能不是。

话虽如此，我想不出一个不是错误的警告的好例子。我的意思是，如果你费心记录警告，你还不如解决潜在的问题。

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

小开
最佳答案

我一般赞同以下惯例：

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

我总是考虑警告第一个日志级别，这肯定意味着有问题（例如，也许配置文件不是它应该在的地方，我们将不得不使用默认设置运行）。一个错误意味着，对我来说，这意味着软件的主要目标现在是不可能的，我们将尝试干净地关闭。

小开

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

在开发中，我经常使用警告，我可能会在其中放置相当于断言失败的内容，但应用程序可以继续工作；这使我能够找出这种情况是否真的发生过，或者是否只是我的想象。

但是，是的，它可以归结为可恢复性和现实性方面。如果您可以恢复，那可能是一个警告；如果它导致某些事情实际上失败，那就是一个错误。

小开

G'day，

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

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

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

HTH

小开

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

我能补充的是，这些级别通常对应于它们的字典定义，所以不会那么难。如果有疑问，把它当作一个谜题。对于你的特定项目，想想你可能想要记录的一切。

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

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

在致命或错误下面，我建议更多的信息总是比更少的好，所以“向上”出错。不确定是信息还是警告？那就把它当作警告。

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

以下是一些例子：

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

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

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

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

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

小开

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

如果您在警告级别捕获并想要一些与警告相关的调试信息，但无法重新创建警告，会发生什么？

捕获一切并稍后过滤！

即使对于嵌入式软件也是如此，除非您发现您的处理器跟不上，在这种情况下，您可能希望重新设计跟踪以使其更高效，或者跟踪会干扰时序（您可能考虑在更强大的处理器上调试，但这会打开一大堆蠕虫）。

捕获一切并稍后过滤！

（顺便说一句，捕获所有内容也很好，因为它可以让您开发工具来做的不仅仅是显示调试跟踪（我从我的中绘制消息序列图和内存使用直方图。如果将来出现问题，它还为您提供了比较的基础（保留所有日志，无论是通过还是失败，并确保在日志文件中包含构建号））。

小开

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

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

错误：这绝对是一个需要调查的问题。SysAdmin应该会自动收到通知，但不需要被拖下床。通过过滤日志来查看错误，你可以大致了解错误频率，并可以快速识别可能导致一系列额外错误的启动失败。跟踪错误率与应用程序使用情况可以产生有用的质量指标，如MTBF，可用于评估整体质量。例如，这个指标可能有助于决定在发布之前是否需要另一个beta测试周期。

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

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

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

调试：我们考虑Debug

小开

我建议采用Syslog严重性级别：DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY。
http://en.wikipedia.org/wiki/Syslog#Severity_levels

它们应该为大多数用例提供足够细粒度的严重级别，并被现有的日志解析器识别。当然，你可以自由地只实现一个子集，例如DEBUG, ERROR, EMERGENCY，具体取决于你的应用程序的要求。

让我们对已经存在多年的东西进行标准化，而不是为我们制作的每个不同的应用程序制定自己的标准。一旦您开始聚合日志并尝试检测不同日志的模式，它真的很有帮助。

小开

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

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

然而，当我戴着系统管理员的帽子，甚至是技术支持的帽子时，我喜欢在我的错误日志中看到一个日志记录级别：OPER，用于OPERATIONAL消息。我用它来记录时间戳、调用的操作类型、提供的参数、可能是（唯一的）任务标识符和任务完成。它用于例如触发独立任务时，这是来自更大的长期运行应用程序中的真正调用。这是我希望始终记录的那种事情，无论是否出现任何问题，所以我认为OPER的级别高于FATAL，所以你只能通过进入完全静默模式来关闭它。它不仅仅是INFO日志数据-一个日志级别经常被滥用于垃圾邮件日志，其中包含没有任何历史价值的次要操作消息。

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

小开

以下是“记录器”所拥有的列表。

Apache log4j：§1，§2

  1. FATAL：

    [v1.2：…]可能导致应用程序中止的非常严重的错误事件。

    [v2.0：…]将阻止应用程序继续的严重错误。

  2. ERROR：

    [v1.2：…]可能仍允许应用程序继续运行的错误事件。

    [v2.0：…]应用程序中的错误，可能可恢复。

  3. WARN：

    [v1.2：…]潜在的有害情况。

    [v2.0：…]可能导致[原文如此]错误的事件。

  4. INFO：

    [v1.2：…]在粗粒度级别突出显示应用程序进度的信息性消息。

    [v2.0：…]用于信息目的的事件。

  5. DEBUG：

    [v1.2：…]对调试应用程序最有用的细粒度信息事件。

    [v2.0：…]常规调试事件。

  6. TRACE：

    [v1.2：…]比DEBUG更细粒度的信息事件。

    [v2.0：…]细粒度调试消息，通常捕获通过应用程序的流。

Apache Httpd（像往常一样）喜欢过度杀戮：§

  1. 紧急：

    紧急情况-系统无法使用。

  2. 警报：

    必须立即采取行动[但系统仍然可用]。

  3. Crit：

    关键条件[但不需要立即采取行动]。

    • "套接字：获取套接字失败，退出子节点"

  4. 错误：

    错误条件[但不是关键]。

    • "脚本头过早结束"

  5. 警告：

    警告条件。[接近错误，但不是错误]

  6. 通知：

    正常但重要的[引人注目]条件。

    • "htpd：捕获#0，试图将核心转储到…"

  7. 信息：

    信息[和不值得注意的]。

    • 【"服务器已运行x小时。"】

  8. 调试：

    调试级消息[，即为去虫）记录的消息]。

    • "打开配置文件…"

  9. trace1→trace6：

    跟踪消息[，即为追踪而记录的消息]。

    • "代理：FTP：控制连接完成"
    • "代理：CONNECT：将CONNECT请求发送到远程代理"
    • "openssl：握手：开始"
    • "从缓冲SSL旅读取，模式0,17字节"
    • "地图查找失败：#0#1"
    • "缓存查找失败，强制进行新的地图查找"

  10. 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共享日志记录：§

  1. 致命：

    导致过早终止的严重错误。希望这些错误在状态控制台上立即可见。

  2. 错误：

    其他运行时错误或意外情况。预计这些将在状态控制台上立即可见。

  3. 警告：

    使用已弃用的API、API使用不当、“几乎”错误、其他不受欢迎或意外但不一定“错误”的运行时情况。期望这些在状态控制台上立即可见。

  4. 信息：

    有趣的运行时事件（启动/关闭）。期望这些在控制台中立即可见，因此要保守并保持在最低限度。

  5. 调试：

    有关通过系统的流程的详细信息。预计这些只能写入日志。

  6. 跟踪：

    更详细的信息。预计这些将仅写入日志。

用于企业使用的Apache共享日志记录“最佳实践”根据它们跨越的边界类型区分调试和信息。

边界包括：

  • 外部边界-预期的例外。

  • 外部边界-意外异常。

  • 内部边界。

  • 重要的内部边界。

（请参阅公地测井指南了解更多信息。

小开

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

每个消息优先级也有一个十进制严重性级别指示器。下表描述了这些参数及其数值值。严重性值必须在0到7（含）的范围内。

       Numerical         SeverityCode
0       Emergency: system is unusable1       Alert: action must be taken immediately2       Critical: critical conditions3       Error: error conditions4       Warning: warning conditions5       Notice: normal but significant condition6       Informational: informational messages7       Debug: debug-level messages
Table 2. Syslog Message Severities
小开

我建议只使用三个级别

  1. 致命-这将破坏应用程序。
  2. 信息-信息
  3. 调试-不太重要的信息
小开

我的两分钱关于FATAL和TRACE错误日志级别。

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

FATAL实际上是DOUBLE FAULT：处理异常时发生异常。

对于Web服务来说很容易理解。

  1. 请求来了。事件记录为INFO
  2. 系统检测到磁盘空间不足。事件记录为WARN
  3. 调用某些函数来处理请求。当处理除以零时发生。事件记录为ERROR
  4. Web服务的异常处理程序被调用来处理除以零。Web服务/框架将发送电子邮件，但它不能，因为邮件服务现在离线。第二个异常无法正常处理，因为Web服务的异常处理程序无法处理异常。
  5. 调用不同的异常处理程序。事件记录为FATAL

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

所以通常在你的程序中你会做DEBUG、INFO和WARN日志记录。只有当你编写一些Web服务/框架时，你才会使用FATAL。当你调试应用程序时，你会从这种类型的软件中得到TRACE日志记录。

小开

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

备忘单：我应该使用哪个日志级别

小开

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

我部分同意他的意见，虽然有一些变化。

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

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

从https://sematext.com/blog/slf4j-tutorial/：

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

有趣的是微软如何在他们的新准标准Microsoft.Extensions.Logging中定义不同的日志级别值（强调我的）：

关键

描述无法恢复的应用程序或系统的日志崩溃，或需要立即处理的灾难性故障。

错误

当当前执行流停止时突出显示的日志失败。这些应该表示当前活动中的失败，不是应用程序范围的故障。

警告

在应用程序中突出显示异常或意外事件的日志流，但不会导致应用程序执行停止。

信息

跟踪应用程序一般流程的日志。这些日志应该长期价值.

调试

在开发过程中用于交互式调查的日志。这些日志应该主要包含对调试有用的信息没有长期价值.

Trace

包含最详细消息的日志。这些消息可能包含敏感应用数据。这些消息被禁用默认且应该永远不会在正式生产环境中启用。


提交答案