日志记录级别-Logback-分配日志级别的经验法则

我在当前项目中使用了logback。

它提供了六种日志记录级别：TRACE DEBUG INFO WARN ERROR OFF

我正在寻找确定常规活动日志级别的经验法则。例如，如果线程被锁定，则应将日志消息设置为调试级别还是信息级别。或者，如果正在使用套接字，则应在调试级别或跟踪级别记录其特定ID。

对于每个日志记录级别的更多示例，我将不胜感激。

我主要构建大型，高可用性类型的系统，因此我的回答偏向于从生产支持的角度来看它。也就是说，我们大致分配如下：

• 错误：系统处于困境中，客户可能受到影响（或将很快受到影响），并且修复可能需要人工干预。“ 2AM规则”在这里适用-如果您正在通话中，如果发生这种情况，是否要在2AM醒来？如果是，则将其记录为“错误”。

• 警告：发生了意外的技术或业务事件，可能会影响客户，但可能不需要立即进行人工干预。待命人员不会立即被呼叫，但是支持人员将希望尽快查看这些问题以了解其影响。基本上，任何需要跟踪但可能不需要立即干预的问题。

• info：如果需要法医分析问题，我们希望大量查看。系统生命周期事件（系统启动，停止）在此处。“会话”生命周期事件（登录，注销等）转到此处。还应考虑重要的边界事件（例如，数据库调用，远程API调用）。典型的业务异常可能会在这里出现（例如，由于凭据不正确导致登录失败）。您认为需要在批量生产中看到的任何其他事件都在这里。

• 调试：几乎所有不会导致“信息”中断的事情……任何有助于跟踪系统流程和隔离问题的消息，尤其是在开发和质量保证阶段。我们将“调试”级别的日志用于大多数非平凡方法的进入/退出，并在方法内部标记有趣的事件和决策点。

• trace：我们不经常使用此日志，但这将用于非常详细甚至潜在的大容量日志，即使在正常开发期间，您通常也不希望启用这些日志。示例包括转储完整的对象层次结构，在大循环的每次迭代期间记录一些状态等。

与选择正确的日志级别相比，更为重要的是确保日志有意义并具有所需的上下文。例如，您几乎总是希望在日志中包括线程ID，以便在需要时可以跟踪单个线程。您可能还希望采用一种机制来将业务信息（例如，用户ID）与线程相关联，以便也将其记录下来。在您的日志消息中，您需要包含足够的信息以确保该消息是可操作的。诸如“捕获FileNotFound异常”之类的日志不是很有帮助。更好的消息是“尝试打开配置文件时捕获了FileNotFound异常：/usr/local/app/somefile.txt。userId = 12344。”

这里也有许多不错的日志记录指南...例如，这是来自JCL（雅加达公共日志记录）的编辑后的片段：

• 错误-其他运行时错误或意外情况。希望它们在状态控制台上立即可见。
• 警告-使用已弃用的API，API使用不当，“几乎”错误，其他运行时情况是不希望的或意外的，但不一定是“错误的”。希望它们在状态控制台上立即可见。
• 信息-有趣的运行时事件（启动/关闭）。希望这些内容在控制台上立即可见，因此请保持保守并尽量减少。
• 调试-有关通过系统的流的详细信息。期望这些仅写入日志。
• 跟踪-更详细的信息。期望这些仅写入日志。

我认为，我的方法更多的是从开发而非操作的角度来看：

• 错误意味着某些任务的执行无法完成；电子邮件无法发送，页面无法呈现，某些数据无法存储到数据库中，诸如此类。绝对有问题。
• 警告表示发生了意外情况，但是执行可以继续进行，可能处于降级模式。缺少配置文件，但使用默认值，价格计算为负，因此将其限制为零，依此类推。有些不正确，但尚未正确出错-警告通常是预示着一个错误很快。
• 信息表示发生了正常但重要的事情；系统启动，系统停止，运行每日库存更新作业等。不应连续不断地读取这些内容，否则将有太多内容可供阅读。
• 调试意味着发生了一些正常且无关紧要的事情；一个新用户来到该网站，呈现了一个页面，下了订单，更新了价格。这是信息中排除的内容，因为其中太多了。
• 跟踪是我从未真正使用过的东西。

鉴于配置了部署的有效日志记录级别，这也可能会对您有所帮助，以了解某个级别的日志记录请求（来自代码）是否会导致实际记录。从此处的其他“答案”中确定您要使用哪种配置来配置部署的有效级别，然后参考此命令以查看是否会实际记录代码中的特定记录请求，然后...

例如：

• “在WARN处记录的记录代码行实际上会记录在配置有ERROR的部署中吗？” 桌子上说，不。
• “在WARN处记录的记录代码行是否实际上会记录在配置有DEBUG的部署中？” 桌子上说是。

从logback文档：

以更图形化的方式，这是选择规则的工作方式。在下表中，垂直标题显示记录请求的级别，由p表示，而水平标题显示记录器的有效级别，由q表示。行（级别请求）和列（有效级别）的交集是根据基本选择规则得出的布尔值。

因此，仅当其部署的有效日志记录级别小于或等于该代码行请求的严重性级别时，才会实际记录请求日志记录的代码行。

我从基于组件的体系结构中回答这个问题，在该体系结构中，组织可能正在运行许多彼此依赖的组件。在传播失败期间，日志记录级别应有助于识别受影响的组件和根本原因。

• 错误 -该组件发生了故障，原因被认为是内部的（任何内部的，未处理的异常，封装的依赖项的故障...例如数据库，REST示例，因为它已从依赖项接收到4xx错误）。让我（该组件的维护者）下床。

• 警告 -该组件发生了故障，该故障被认为是由从属组件引起的（REST示例将是从属从属的5xx状态）。让THAT组件的维护者下床。

• 信息 -我们想要与操作员联系的其他事项。如果您决定记录快乐路径，那么我建议每个重要操作（例如，每个传入的HTTP请求）限制为1条日志消息。

对于所有日志消息，请确保记录有用的上下文（并优先考虑使消息易于阅读/使用，而不要大量“错误代码”）

• 调试（及以下）-绝对不应该使用（当然也不能在生产中使用）。在开发中，我建议结合使用TDD和Debugging（在必要时），而不是使用日志语句污染代码。在生产中，上面的INFO日志以及其他度量标准应该足够了。

可视化上述日志记录级别的一种好方法是为每个组件设想一组监视屏幕。当所有组件运行良好时，它们为绿色，如果组件记录警告，则它将变为橙色（琥珀色），如果任何组件记录为错误，则它将变为红色。

如果发生事件，您应该使一个（根本原因）组件变为红色，并且所有受影响的组件应变为橙色/琥珀色。

对于其他答案也没有什么不同，我的框架几乎具有相同的级别：

1. 错误：应用程序上的严重逻辑错误，例如数据库连接超时。需要在不久的将来进行错误修复的事情
2. 警告：没有中断的问题，但是需要注意的地方。就像找不到请求的页面一样
3. 信息：在函数/方法的第一行中使用，以显示已被调用的过程或执行的步骤正常，例如已完成插入查询
4. log：逻辑信息，如if语句的结果
5. 调试：与永久性相关的变量内容