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

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

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

什么是好的启发式方法?


当前回答

顺便说一句,我非常喜欢捕捉一切,然后过滤信息。

如果您在“警告”级别捕获,并希望获得与警告相关的一些调试信息,但无法重新创建警告,会发生什么情况?

捕获所有内容并稍后过滤!

即使对于嵌入式软件,这也是正确的,除非你发现你的处理器跟不上,在这种情况下,你可能需要重新设计你的跟踪以使其更高效,或者跟踪干扰了时间(你可能会考虑在一个更强大的处理器上调试,但这会带来另一种蠕虫)。

捕获所有内容并稍后过滤!!

(顺便说一句,捕获一切也很好,因为它让您可以开发工具来做更多的工作,而不仅仅是显示调试跟踪(我从中绘制了消息序列图,以及内存使用情况的直方图。它还为您提供了一个基础,以便在将来发生错误时进行比较(保留所有日志,无论是通过还是失败,并确保在日志文件中包含内部版本号))。

其他回答

错误是一种错误的东西,很明显是错误的,没有办法解决它,它需要被修复。

警告是一种模式的信号,这种模式可能是错误的,但也可能不是。

话虽如此,但我无法提出一个警告的好例子,这不是一个错误。我的意思是,如果您遇到了记录警告的麻烦,那么不妨解决根本问题。

然而,像“sql执行时间过长”这样的情况可能是一个警告,而“sql执行死锁”是一个错误,所以可能毕竟存在一些情况。

在此之前,我已经构建了以下系统:

错误-表示出现了严重错误,特定线程/进程/序列无法继续。需要一些用户/管理员干预警告-有些事情不正确,但过程可以照常进行(例如,一组100个作业中的一个作业失败,但剩余的作业可以处理)

在我所构建的系统中,管理员都在接受指示,以应对错误。另一方面,我们将观察警告,并确定每种情况是否需要任何系统更改、重新配置等。

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

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

我的两分钱关于致命和跟踪错误日志级别。

ERROR(错误)是指发生某些FAULT(异常)时。

致命实际上是双重故障:在处理异常时发生异常。

web服务很容易理解。

请求来了。事件记录为INFO系统检测到磁盘空间不足。事件记录为警告调用某个函数来处理请求。当处理被零除时。事件记录为ERROR调用Web服务的异常处理程序来处理除以零的操作。Web服务/框架将发送电子邮件,但无法发送,因为邮件服务现在处于脱机状态。第二个异常无法正常处理,因为Web服务的异常处理程序无法处理异常。调用了不同的异常处理程序。事件记录为致命

TRACE是我们可以跟踪函数入口/出口的时间。这与日志无关,因为此消息可以由某些调试器生成,而您的代码根本没有调用日志。因此,非来自应用程序的消息被标记为TRACE级别。例如,使用strace运行应用程序

因此,通常在程序中,您会进行DEBUG、INFO和WARN日志记录。只有当你正在编写一些web服务/框架时,你才会使用FATAL。当您调试应用程序时,您将从这种类型的软件获得TRACE日志记录。

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


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日志记录指南。)