Question

根据死亡率，有不同的方式来记录消息：

FATAL
ERROR
WARN
INFO
DEBUG
TRACE

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

使用什么是好的启发式？

Answer 1

我通常订阅以下约定：

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

Answer 2

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

是 - ＆gt;错误
不 - ＆gt;警告

Answer 3

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

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

错误：绝对是一个应该调查的问题。应自动通知SysAdmin，但不需要将其拖出床。通过过滤日志以查看错误及以上，您可以获得错误频率的概述，并可以快速识别可能导致一系列其他错误的启动失败。跟踪错误率与应用程序使用情况相比可以产生有用的质量指标，例如MTBF，可用于评估整体质量。例如，此指标可能有助于在发布之前决定是否需要另一个beta测试周期。

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

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

跟踪：跟踪是目前最常用的严重性，应提供上下文以了解导致错误和警告的步骤。具有适当密度的跟踪消息使得软件更易于维护，但需要一些勤奋，因为随着程序的发展，各个Trace语句的价值可能会随着时间而变化。实现这一目标的最佳方法是让开发团队习惯定期查看日志，作为解决客户报告问题的标准部分。鼓励团队删除不再提供有用上下文的跟踪消息，并在需要时添加消息以了解后续消息的上下文。例如，记录用户输入（例如更改显示或标签）通常很有帮助。

调试：我们认为Debug＆lt;跟踪。区别在于Debug消息是从Release版本编译而来的。也就是说，我们不鼓励使用Debug消息。允许调试消息往往会导致添加越来越多的调试消息，并且不会删除任何消息。随着时间的推移，这会使日志文件几乎无用，因为过于难以从噪声中过滤信号。这导致开发者不使用继续死亡螺旋的原木。相比之下，不断修剪跟踪消息会鼓励开发者使用它们，从而形成良性循环。此外，这消除了由于调试代码中未包含在发布版本中所需的副作用而引入错误的可能性。是的，我知道不应该在良好的代码中发生，但更安全然后抱歉。

Answer 4

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

Answer 5

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

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

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

Answer 6

这里列出了记录器＆＃34;记录器＆＃34;有

Apache log4j：§1，§2

FATAL：

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

[ v2.0 ：..]严重错误会阻止应用程序继续运行。
ERROR：

[ v1.2 ：..]错误事件可能仍允许应用程序继续运行。
应用程序中的
[ v2.0 ：..]错误，可能是可恢复的。
WARN：

[ v1.2 ：..]可能有害的情况。

[ v2.0 ：..]可能导致[ sic ]的事件导致错误。
INFO：

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

[ v2.0 ：..]事件仅供参考。
DEBUG：

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

[ v2.0 ：..]一般调试事件。
TRACE：

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

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

Apache Httpd（像往常一样）喜欢寻找过度杀伤力：§

<强> EMERG ：

紧急情况 - 系统无法使用。
<强>警报：

必须立即采取行动[但系统仍可使用]。
暴击：
关键条件[但不需要立即采取行动]。
- ＆＃34; socket：无法获得套接字，退出孩子＆＃34;
错误：


错误条件[但不严重]。


＆＃34; 脚本标题的提前结束＆＃34;

<强>警告：


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

<强>通知：


正常但重要的[notable]条件。


＆＃34; httpd：抓住SIGBUS，试图将核心转储到... ＆＃34;


<强>信息：


信息[和不可注意]。


[＆＃34; 服务器已运行x小时。＆＃34;]


<强>调试：


调试级别消息[，即为 de-bugging 而记录的消息]]。


＆＃34; 打开配置文件... ＆＃34;


trace1 → trace6 ：


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


＆＃34; 代理：FTP：控制连接完成＆＃34;

＆＃34; proxy：CONNECT：将CONNECT请求发送到远程代理＆＃34;

＆＃34; openssl：握手：开始＆＃34;

＆＃34; 从缓冲的SSL旅中读取，模式0,17字节＆＃34;

＆＃34; 地图查找失败：map=rewritemap key=keyname ＆＃34;

＆＃34; 缓存查找失败，强制新地图查找＆＃34;


trace7 → trace8 ：


跟踪消息，转储大量数据


＆＃34; | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 | ＆＃34;

＆＃34; | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 | ＆＃34;


Apache commons-logging：§

<强>致命：


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

错误：


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

<强>警告：


使用已弃用的API，API使用不当，几乎＆＃39;错误，其他不期望或意外的运行时情况，但不一定＆＃34;错误＆＃34;。期望这些在状态控制台上立即可见。

<强>信息：


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

<强>调试：


有关通过系统的流量的详细信息。期望这些只写入日志。

<强>微量：


更详细的信息。期望这些只写入日志。

Apache commons-logging＆＃34;最佳实践＆＃34;对于企业使用，根据它们跨越的边界类型区分 debug 和 info 。

边界包括：

外部边界 - 预期的例外情况。

外部边界 - 意外的异常。

内部边界。

重要的内部边界。

（有关详细信息，请参阅commons-logging guide。）

Answer 7

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

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

对比试图将该信息写入数据库并连续60秒返回网络消息。这更像是一个错误，而不是一个警告。

Answer 8

这是一个古老的话题，但仍然有意义。本周，我为我的同事写了一篇小文章。为此，我还创建了该备忘单，因为我无法在线找到任何内容。

Answer 9

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

在开发中，我经常使用警告，我可能会将相应的断言失败，但应用程序可以继续工作;这使我能够发现这种情况是否真的发生过，或者这是否是我的想象。

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

Answer 10

我认为SYSLOG级别NOTICE和ALERT / EMERGENCY对于应用程序级别的日志记录来说基本上是多余的 - 而CRITICAL / ALERT / EMERGENCY对于可能触发不同操作和通知的操作员来说可能是有用的警报级别，对于应用程序管理员来说它是全部与致命一样。我只是不能充分区分给予通知或某些信息。如果信息不值得注意，那就不是真正的信息：）

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

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

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

Answer 11

错误是错误的，完全错误的，没有解决方法，需要修复。

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

话虽如此，我无法想出一个警告的好例子，这也不是一个错误。我的意思是，如果你遇到记录警告的麻烦，你也可以解决潜在的问题。

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

Answer 12

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

Answer 13

来自Ietf - 第10页

Each message Priority also has a decimal Severity level indicator.

下表中描述了它们及其数字值。严重性值必须在0到7的范围内。

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

Answer 14

我完全赞同其他人，并认为GrayWizardx说得最好。

我可以补充的是，这些级别通常对应于它们的字典定义，所以它不会那么难。如果有疑问，请将其视为谜题。对于您的特定项目，请考虑您可能要记录的所有内容。

现在，你能弄明白什么可能是致命的吗？你知道fatale意味着什么，不是吗？那么，你名单上的哪些项目是致命的。

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

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

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

以下是一些例子：

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

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

警告 - 资源分配达到X％（比如说80％） - 这表示您可能需要重新标注您的尺寸。

信息 - 用户登录/退出，新交易，文件包装，新d / b字段或字段已删除。

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

Answer 15

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

ERROR是发生某些故障（异常）的时间。

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

对于Web服务很容易理解。

请求来。事件记录为INFO
系统检测到磁盘空间不足。事件记录为WARN
调用了一些函数来处理请求。在进行除以零的处理时。事件记录为ERROR
调用Web服务的异常处理程序以处理零除。 Web服务/框架将发送电子邮件，但是不能，因为邮件服务现在处于脱机状态。第二个异常无法正常处理，因为Web服务的异常处理程序无法处理异常。
调用了不同的异常处理程序。事件记录为FATAL

TRACE是我们可以跟踪函数进入/退出的时间。这与记录无关，因为此消息可以由某些调试器生成，并且您的代码根本没有调用log。因此，不是来自您的应用程序的消息将被标记为TRACE级。例如，您使用strace

运行应用程序

因此，通常在程序中执行DEBUG，INFO和WARN日志记录。并且只有在编写某些Web服务/框架时，您才使用FATAL。而且，当您调试应用程序时，将从此类软件获得TRACE日志记录。

Answer 16

天儿真好，

作为此问题的必然结果，请传达您对日志级别的解释，并确保项目中的所有人员对其级别的解释保持一致。

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

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

HTH

Answer 17

顺便说一下，我非常喜欢捕捉所有内容并在以后过滤信息。

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

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

即使对于嵌入式软件也是如此，除非您发现处理器无法跟上，在这种情况下您可能需要重新设计跟踪以提高其效率，或者跟踪会干扰时序（您< em>可能考虑在功能更强大的处理器上进行调试，但这会打开一整套蠕虫病毒。）

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

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

Answer 18

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

错误 - 意味着某些事情严重错误，并且特定的线程/进程/序列无法继续。需要一些用户/管理员干预
警告 - 某些内容不对，但该过程可以像以前一样继续进行（例如100个中的一个作业失败，但其余部分可以处理）

在我建立的系统中，管理员正在接受指令以对ERROR做出反应。另一方面，我们会关注警告并确定每种情况是否需要更改系统，重新配置等。

Answer 19

我建议只使用三个级别

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

Answer 20

Taco Jan Osinga's answer很好而且很实用。

尽管有些变化，但我与他部分同意。

在 Python 上有only 5 "named" logging levels，所以这是我的使用方式：

DEBUG-对故障排除很重要的信息，通常在正常的日常操作中会被抑制
INFO –作为程序执行其设计功能的“证明”的日常操作
WARN-超出正常但可以恢复的情况，*或*可能会导致导致未来问题的事物
ERROR －发生了一些事情，使得程序必须进行恢复，但是恢复是成功的。但是，该程序可能未处于最初的预期状态，因此该程序的用户将需要进行调整
CRITICAL-无法恢复的事情发生了，程序可能需要终止，以免每个人都生活在一种罪恶状态中

何时使用不同的日志级别

20 个答案: