有不同的方式记录消息,按死亡顺序排列:

致命的错误警告信息调试,调试跟踪

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

什么是好的启发式方法?


当前回答

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

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

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

其他回答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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