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

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

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

什么是好的启发式方法?


当前回答

我建议采用Syslog严重级别:调试、信息、通知、警告、错误、严重、警报、紧急。看见http://en.wikipedia.org/wiki/Syslog#Severity_levels

它们应该为大多数用例提供足够的细粒度严重性级别,并被现有的日志解析器识别。当然,您可以根据应用程序的要求,自由地只实现一个子集,例如调试、错误、紧急情况。

让我们对已有多年的应用程序进行标准化,而不是为我们制作的每个不同应用程序制定自己的标准。一旦您开始聚合日志并尝试检测不同日志之间的模式,这将非常有用。

其他回答

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

是->错误无->警告

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

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

下面是“伐木工人”的清单。


Apache日志4j:§1,§2

致命:[v1.2:..]非常严重的错误事件,可能会导致应用程序中止。[v2.0:..]严重错误,将阻止应用程序继续运行。错误:[v1.2:..]可能仍然允许应用程序继续运行的错误事件。[v2.0:..]应用程序中的错误,可能可以恢复。警告:[v1.2:..]潜在的有害情况。[v2.0:..]事件可能导致错误。信息:[v1.2:..]在粗粒度级别突出显示应用程序进度的信息性消息。[v2.0:..]事件,仅供参考。调试:[v1.2:..]对调试应用程序最有用的细粒度信息事件。[v2.0:..]常规调试事件。跟踪:[v1.2:..]比DEBUG更细粒度的信息事件。[v2.0:..]细粒度调试消息,通常捕获通过应用程序的流。


Apache Httpd(和往常一样)喜欢过度使用:§

紧急情况:紧急情况–系统不可用。警觉的:必须立即采取行动[但系统仍然可用]。比容:关键条件[但无需立即采取行动]。套接字:无法获取套接字,正在退出子级错误:错误条件[但不重要]。“脚本头过早结束”警告:警告条件。[接近错误,但不是错误]通知:正常但显著的情况。httpd:捕获SIGBUS,试图在中转储核心信息:信息[和不可旋转]。[“服务器已运行x小时。”]调试:调试级消息[,即为调试而记录的消息)]。“正在打开配置文件…”痕迹1→ 痕迹6:跟踪消息[,即为跟踪而记录的消息]。“代理:FTP:控制连接完成”“proxy:CONNECT:向远程代理发送CONNECT请求”“openssl:握手:启动”“从缓冲SSL旅读取,模式0,17字节”“地图查找失败:map=rewriteitemap key=keyname”缓存查找失败,强制新的映射查找痕迹7→ 痕迹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日志记录:§

致命:导致提前终止的严重错误。期望这些在状态控制台上立即可见。错误:其他运行时错误或意外情况。期望这些在状态控制台上立即可见。警告:使用不推荐使用的API、API使用不当、“几乎”错误、其他不希望或意外但不一定“错误”的运行时情况。期望这些在状态控制台上立即可见。信息:有趣的运行时事件(启动/关闭)。期望这些在控制台上立即可见,所以要保守,尽量减少。调试:有关通过系统的流程的详细信息。期望这些仅写入日志。跟踪:更详细的信息。期望这些仅写入日志。

Apache commons记录企业使用的“最佳实践”,根据调试和信息跨越的界限来区分它们。

边界包括:

外部边界-预期异常。外部边界-意外异常。内部边界。重要内部边界。

(有关详细信息,请参阅commons日志记录指南。)

我建议只使用三个级别

致命-这会破坏应用程序。信息-信息调试-不太重要的信息

我认为,对于应用程序级别的日志记录来说,SYSLOG级别NOTICE和ALERT/EEMERGENCY在很大程度上是多余的-而CRITICAL/ALERT/EEMGENCY对于可能触发不同操作和通知的操作员来说可能是有用的警报级别,但对于应用程序管理员来说,这与FATAL相同。我只是无法充分区分被通知还是一些信息。如果信息不值得注意,那么它就不是真正的信息:)

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

然而,对于OPERATIONAL消息,当我戴着系统管理员和技术支持甚至开发人员的帽子时,我希望在错误日志中看到一个日志级别。我使用它来记录时间戳、调用的操作类型、提供的参数、可能的(唯一)任务标识符和任务完成情况。例如,当一个独立的任务被启动时,它就被使用了,这是一个来自大型长时间运行的应用程序的真正调用。这是我希望始终记录的事情,无论是否有任何问题,所以我认为OPER级别高于致命级别,因此您只能通过进入完全静音模式来关闭它。它不仅仅是INFO日志数据,这是一个日志级别,经常被滥用,用于发送没有任何历史价值的小操作消息。

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