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

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

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

什么是好的启发式方法?


当前回答

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

其他回答

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

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

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

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

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

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

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

从…起https://sematext.com/blog/slf4j-tutorial/:

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

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

根据RFC 5424,系统日志协议(IETF)-第10页:

每个消息优先级也有一个十进制严重性级别指示符。下表中描述了这些参数及其数值价值观严重性值必须介于0到7之间(含0到7)。数值严重性密码0紧急情况:系统不可用1警报:必须立即采取行动2临界:临界条件3错误:错误条件4警告:警告条件5注意:正常但重要的情况6信息:信息性消息7调试:调试级别消息表2。Syslog消息严重性

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

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

与之形成对比的是,尝试将信息写入数据库,并连续60秒返回网络关闭消息。这与其说是警告,不如说是错误。