有不同的方式记录消息,按死亡顺序排列:
致命的错误警告信息调试,调试跟踪
我如何决定何时使用哪个?
什么是好的启发式方法?
有不同的方式记录消息,按死亡顺序排列:
致命的错误警告信息调试,调试跟踪
我如何决定何时使用哪个?
什么是好的启发式方法?
当前回答
你想让系统管理员半夜起床吗?
是->错误无->警告
其他回答
我建议只使用三个级别
致命-这会破坏应用程序。信息-信息调试-不太重要的信息
正如其他人所说,错误是问题;警告是潜在的问题。
在开发中,我经常使用警告,在警告中,我可能会放置相当于断言失败,但应用程序可以继续工作;这使我能够发现这个案子是否真的发生过,或者这是我的想象。
但是的,它归结到恢复性和现实性方面。如果你能恢复,那可能是一个警告;如果它导致某个东西实际失败,那就是一个错误。
我一直在考虑警告第一个日志级别,这肯定意味着存在问题(例如,可能配置文件不在应该的位置,我们将不得不使用默认设置运行)。对我来说,一个错误意味着软件的主要目标现在不可能实现,我们将尝试彻底关闭。
根据RFC 5424,系统日志协议(IETF)-第10页:
每个消息优先级也有一个十进制严重性级别指示符。下表中描述了这些参数及其数值价值观严重性值必须介于0到7之间(含0到7)。数值严重性密码0紧急情况:系统不可用1警报:必须立即采取行动2临界:临界条件3错误:错误条件4警告:警告条件5注意:正常但重要的情况6信息:信息性消息7调试:调试级别消息表2。Syslog消息严重性
我建议采用Syslog严重级别:调试、信息、通知、警告、错误、严重、警报、紧急。看见http://en.wikipedia.org/wiki/Syslog#Severity_levels
它们应该为大多数用例提供足够的细粒度严重性级别,并被现有的日志解析器识别。当然,您可以根据应用程序的要求,自由地只实现一个子集,例如调试、错误、紧急情况。
让我们对已有多年的应用程序进行标准化,而不是为我们制作的每个不同应用程序制定自己的标准。一旦您开始聚合日志并尝试检测不同日志之间的模式,这将非常有用。