有不同的方式记录消息,按死亡顺序排列:
致命的错误警告信息调试,调试跟踪
我如何决定何时使用哪个?
什么是好的启发式方法?
有不同的方式记录消息,按死亡顺序排列:
致命的错误警告信息调试,调试跟踪
我如何决定何时使用哪个?
什么是好的启发式方法?
当前回答
从…起https://sematext.com/blog/slf4j-tutorial/:
TRACE–具有此级别的日志事件是最细粒度的,通常不需要,除非您需要完全了解应用程序中和所使用的第三方库中发生的情况。您可以期望TRACE日志记录级别非常详细。调试–与TRACE级别相比粒度更小,但仍比日常使用中需要的更多。DEBUG日志级别应用于深入诊断和故障排除所需的信息。INFO–表示发生了什么、应用程序处理了请求等的标准日志级别。使用INFO日志级别记录的信息应该是纯粹的信息,不定期查看这些信息不会导致丢失任何重要信息。警告–指示应用程序中发生意外事件的日志级别。例如,一个问题,或者一个可能会干扰其中一个进程但整个应用程序仍在运行的情况。错误–当应用程序遇到阻止一个或多个功能正常运行的问题时,应使用的日志级别。当其中一个支付系统不可用时,可以使用ERROR日志级别,但仍然可以选择在电子商务应用程序中检查购物篮,或者当您的社交媒体日志选项由于某种原因无法工作时。您还可以看到与异常相关的ERROR日志级别。
其他回答
错误是一种错误的东西,很明显是错误的,没有办法解决它,它需要被修复。
警告是一种模式的信号,这种模式可能是错误的,但也可能不是。
话虽如此,但我无法提出一个警告的好例子,这不是一个错误。我的意思是,如果您遇到了记录警告的麻烦,那么不妨解决根本问题。
然而,像“sql执行时间过长”这样的情况可能是一个警告,而“sql执行死锁”是一个错误,所以可能毕竟存在一些情况。
微软如何在其新的准标准Microsoft.Extension.Logging中定义不同的LogLevel值非常有趣(重点是我的):
批评的描述不可恢复的应用程序或系统崩溃或需要立即关注的灾难性故障。错误当前执行流停止时突出显示的日志失败。这些应指示当前活动中的故障,而不是应用程序范围内的故障。警告突出显示应用程序中异常或意外事件的日志但不会导致应用程序执行停止。信息跟踪应用程序一般流程的日志。这些日志应该具有长期价值。调试开发期间用于交互式调查的日志。这些日志应主要包含对调试有用的信息并且没有长期价值。查出包含最详细消息的日志。这些消息可能包含敏感应用程序数据。这些消息被禁用默认设置,在生产环境中永远不应启用。
这是一个古老的话题,但仍然相关。本周,我为同事们写了一篇关于它的小文章。出于这个目的,我还制作了这个备忘单,因为我在网上找不到。
我一直在考虑警告第一个日志级别,这肯定意味着存在问题(例如,可能配置文件不在应该的位置,我们将不得不使用默认设置运行)。对我来说,一个错误意味着软件的主要目标现在不可能实现,我们将尝试彻底关闭。
我完全同意其他人的观点,并认为GrayWizardx说得最好。
我所能补充的是,这些级别通常对应于它们的字典定义,所以这并不难。如果有疑问,请像拼图一样对待它。对于您的特定项目,考虑您可能想要记录的所有内容。
现在,你能找出什么可能是致命的吗?你知道什么是致命的,不是吗?那么,你的清单上哪些项目是致命的。
好的,这是致命的问题,现在让我们看看错误。。。冲洗并重复。
在“致命”以下,或者可能是“错误”以下,我建议信息多总比信息少好,所以错误“向上”。不确定是信息还是警告?然后发出警告。
我确实认为,致命和错误应该是我们所有人都清楚的。其他的可能更模糊,但可以说,把它们弄对并不那么重要。
以下是一些示例:
致命-无法分配内存、数据库等-无法继续。
错误-没有回复消息、事务中止、无法保存文件等。
警告-资源分配达到X%(例如80%)-这表明您可能需要重新调整维度。
信息-用户登录/注销、新事务、文件装箱、新d/b字段或删除的字段。
内部数据结构的调试转储,任何带有文件名和行号的跟踪级别。跟踪-操作成功/失败,已更新d/b。