何时使用不同的日志级别

我一般同意以下公约:

• 痕迹 -只有当我“跟踪”代码并试图找到一个时 部分 特定功能的。
• 调试 -不仅仅对开发人员(IT、SysAdmins等)有用的诊断信息。
• 信息 -要记录的一般有用信息(服务启动/停止、配置假设等)。我想随时提供信息,但在正常情况下通常不关心。这是我的开箱即用配置级别。
• 警告 -任何可能导致应用程序异常但我正在自动恢复的东西。(例如从主服务器切换到备份服务器、重试操作、丢失辅助数据等)
• 误差 -任何对 操作 ,但不是服务或应用程序(无法打开所需文件、缺少数据等)。这些错误将强制用户(管理员或直接用户)干预。这些通常是(在我的应用程序中)为错误的连接字符串、丢失的服务等保留的。
• 致命的 -强制关闭服务或应用程序以防止数据丢失(或进一步数据丢失)的任何错误。我只为最严重的错误和保证出现数据损坏或丢失的情况保留这些信息。

您想让系统管理员在半夜起床吗?

• 是的&误差
• 没有&警告

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

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

误差 :肯定是应该调查的问题。系统管理员应该被自动通知,但不需要被拖下床。通过过滤日志来查看错误以及上面的错误,您可以获得错误频率的概述,并可以快速识别可能导致附加错误级联的启动失败。跟踪错误率与应用程序使用情况之间的关系,可以生成有用的质量指标,如MTBF,用于评估总体质量。例如,这个指标可能有助于在发布之前决定是否需要另一个测试周期。

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

信息 :这是在正常情况下应记录的重要信息,如初始化成功、服务启动和停止或重要事务的成功完成。查看显示信息及以上内容的日志应该可以快速概述流程中的主要状态更改,从而提供顶层上下文,以了解任何警告或也会发生的错误。没有太多的信息消息。我们通常有5%的信息消息与跟踪相关。

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

调试 :我们考虑调试跟踪。区别在于调试消息是在发布版本中编译的。也就是说,我们不鼓励使用调试消息。允许调试消息往往会导致越来越多的调试消息被添加,而从来没有删除过。随着时间的推移,这使得日志文件几乎毫无用处,因为很难从噪声中过滤信号。这导致开发人员不使用继续死亡螺旋的日志。相反,不断修剪跟踪消息会鼓励开发人员使用它们,从而导致良性循环。此外,这消除了由于调试代码中需要的副作用而引入的错误的可能性,这些副作用不包括在发布版本中。是的,我知道这不应该发生在好的代码中,但最好是安全的然后抱歉。

这是“伐木工人”的名单。

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 :

   [ 第1.2版 :…]比 调试 .

   [ 2.0版 :..]细粒度调试消息,通常通过应用程序捕获流。

ApacheHTTPD(和往常一样)喜欢过度杀戮: §

1. 埃默格 :

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

2. 警觉的 :

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

3. 克里特 :

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

   • “ 套接字:获取套接字失败,正在退出子级 “

4. 错误 :

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

   • “ 脚本头过早结束 “

5. 警告 :

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

6. 通知 :

   正常但重要[ notable ]条件。

   • “ 抓获 SIGBUS ,正在尝试将核心转储到… “

7. 信息 :

   信息性[不显著]。

   • [ 服务器已运行X小时。 “”

8. 调试 :

   调试级消息[,即为了 去窃听 )

   • “ 正在打开配置文件… “

9. Trace1 渐次 Trace6 :

   跟踪消息[,即为了 示踪 ]

   • “ 代理:ftp:控制连接完成 “
   • “ 代理:连接:将连接请求发送到远程代理 “
   • “ openssl:握手:开始 “
   • “ 从缓冲的SSL旅读取,模式0,17字节 “
   • “ 地图查找失败: map=rewritemap key=keyname “
   • “ 缓存查找失败,强制新的映射查找 “

10. Trace7 渐次 示踪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日志记录: §

1. 致命的 以下内容:

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

2. 错误 :

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

3. 警告 :

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

4. 信息 :

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

5. 调试 :

   有关系统流程的详细信息。希望这些只写在日志中。

6. 追踪 :

   更详细的信息。希望这些只写在日志中。

ApacheCommons日志记录“企业使用的最佳实践”区分了 调试 和 信息 基于他们跨越的边界。

边界包括:

• 外部边界-预期异常。

• 外部边界-意外的异常。

• 内部边界。

• 重要的内部界限。

(见 commons-logging guide 了解更多信息。)

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

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

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

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

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

例如,假设您输入/导入名称 "Angela Müller" 在应用程序中(注意 u )您的代码/数据库可能只是英文的(尽管可能 不应该 因此可以警告所有“不寻常”的字符都已转换为普通的英文字符。

与尝试将该信息写入数据库并连续60秒返回网络故障消息形成对比。这不仅仅是一个警告,更是一个错误。

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

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

但是的,它涉及到可恢复性和现实性方面。如果你能恢复,这可能是一个警告;如果它真的导致了一些事情的失败,那就是一个错误。

我认为对于应用程序级别的日志记录来说,系统日志级别通知和警报/紧急情况在很大程度上是多余的——而对于可能触发不同操作和通知的操作员来说,关键/警报/紧急情况可能是有用的警报级别,对于应用程序管理员来说,这与致命性相同。我只是不能很好地区分被通知和一些信息。如果信息不值得注意,那就不是真正的信息:)

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

但是,当我戴着系统管理员的帽子,甚至戴着技术支持的帽子,甚至戴着开发人员的帽子,查看操作消息时,我喜欢在错误日志中看到一个日志级别。我使用它记录时间戳、调用的操作类型、提供的参数、可能的(唯一)任务标识符和任务完成。当一个独立的任务被触发时,它就被使用了,这是大型长时间运行的应用程序中真正的调用。这是我想要一直记录的事情,不管有没有什么问题,所以我认为操作级别高于致命级别,所以你只能通过进入完全静音模式来关闭它。它不仅仅是信息日志数据——日志级别经常被滥用,因为它向日志发送一些没有任何历史价值的小操作消息。

根据具体情况,这些信息可能被定向到一个单独的调用日志,也可能通过从记录更多信息的大日志中筛选出来获得。但是,作为历史信息,始终需要知道正在做什么——不下降到审计级别,另一个完全独立的日志级别与故障或系统操作无关,不真正适合上述级别(因为它需要自己的控制开关,而不是严重性分类),并且绝对需要它自己独立的日志文件。

错误是错误的东西,明显的错误,没有办法避免它,它需要被修复。

警告是模式的标志 可以 是错的,但也可能不是。

既然这样说了,我就不能想出一个好的例子来说明一个警告,它也不是一个错误。我的意思是,如果您遇到了记录警告的麻烦,那么您也可以修复底层问题。

但是,像“SQL执行时间太长”这样的事情可能是一个警告,而“SQL执行死锁”是一个错误,因此可能毕竟存在一些情况。

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

从 Ietf - Page 10

Each message Priority also has a decimal Severity level indicator.

下表中描述了这些参数及其数值 价值观。严重性值必须介于0到7之间(含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

国庆节,

作为这个问题的推论,交流您对日志级别的解释,并确保项目中的所有人员在对级别的解释中都是一致的。

在严重性和所选日志级别不一致的情况下,看到大量日志消息是很痛苦的。

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

高温高压

我完全同意其他人的观点,认为格雷奇克斯说得最好。

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

现在,你能知道什么是致命的吗?你知道命运是什么意思吧?所以,你清单上的哪些项目是致命的。

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

在致命的,或者可能是错误的下面,我建议更多的信息总是比更少的更好,所以错误是“向上”。不确定是信息还是警告?那就做个警告吧。

我认为我们大家都应该清楚致命的错误。其他人可能更模糊,但可以说,让他们正确无误并不那么重要。

以下是一些例子:

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

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

警告 -资源分配达到了X%(比如80%),这是一个迹象,表明你可能想要重新确定你的维度。

信息 -用户登录/注销、新交易、文件装箱、新D/B字段或删除的字段。

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

在此之前,我已经构建了使用以下功能的系统:

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

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

顺便说一句,我非常喜欢捕捉所有的东西,并在以后过滤信息。

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

俘获 一切 以后再过滤!

即使对于嵌入式软件,这也是正确的,除非您发现处理器无法跟上,在这种情况下,您可能希望重新设计跟踪以提高效率,或者跟踪会干扰时间(您 可以 考虑在一个更强大的处理器上进行调试,但这会打开另一个蠕虫罐头)。

俘获 一切 以后再过滤!!

(顺便说一句,Capture Everything也很好,因为它可以让您开发工具来完成不仅仅是显示调试跟踪(我从我的中绘制了消息序列图,以及内存使用的柱状图)。它还为将来发生错误时的比较提供了基础(保留所有日志,无论是通过还是失败,并确保在日志文件中包含内部版本号)。