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

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严重级别：调试、信息、通知、警告、错误、严重、警报、紧急。看见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消息严重性

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

在此之前，我已经构建了以下系统：

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

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