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

Question

我在当前项目中使用logback。

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

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

我将欣赏每个日志记录级别的更多示例的答案。

Answer 1

我主要构建大规模，高可用性类型的系统，所以我的答案偏向于从生产支持的角度来看待它;那说，我们大致分配如下：

• 错误：系统遇险，客户可能受到影响（或很快就会出现），修复可能需要人工干预。 “2AM规则”适用于此 - 如果您正在通话，如果发生这种情况，您是否希望在凌晨2点被唤醒？如果是，则将其记录为“错误”。

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

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

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

• 跟踪：我们不经常使用此功能，但这适用于即使在正常开发期间通常也不需要启用的极其详细且可能很高的大量日志。示例包括转储完整的对象层次结构，在大循环的每次迭代期间记录某些状态等。

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

还有一些很好的日志记录指南...例如，这是JCL (Jakarta Commons Logging)编辑的片段：

  

  
• 错误 - 其他运行时错误或意外情况。期望这些在状态控制台上立即可见。
  
• 警告 - 使用已弃用的API，API使用不当，“几乎”错误，其他不期望或意外的运行时情况，但不是   必然“错”。期望这些立即可见   状态控制台。
  
• info - 有趣的运行时事件（启动/关闭）。期望这些在控制台上立即可见，所以要保守并坚持下去   至少。
  
• debug - 有关通过系统的流量的详细信息。期望这些只写入日志。
  
• 追踪 - 更详细的信息。期望这些只写入日志。
  

Answer 2

我的方法，我认为更多来自开发而不是运营的观点，是：

• 错误表示无法完成某项任务的执行;无法发送电子邮件，无法呈现页面，某些数据无法存储到数据库中，类似这样的内容。有些东西肯定出错了。
• 警告表示发生意外情况，但执行可能会继续，可能是降级模式;一个配置文件丢失但是使用了默认值，价格被计算为负数，因此它被限制为零等等。有些事情是不对的，但它还没有正确错误 - 警告通常表明会有很快就会出错。
• 信息表示正常但重要的事情发生;系统启动，系统停止，每日库存更新工作运行等等。不应该有这些不断的洪流，否则只是阅读太多了。
• 调试意味着发生了正常而微不足道的事情;一个新用户来到该网站，一个页面被渲染，一个订单，一个价格被更新。这是从信息中排除的东西，因为它会有太多的东西。
• 跟踪是我从未实际使用过的。

Answer 3

这也可能是切向帮助，以了解某个级别的日志记录请求（来自代码）是否会导致实际记录有效日志记录级别部署配置为。从此处的其他Answers确定您要配置部署的有效级别，然后参考此处以查看代码中是否实际记录了特定的日志请求然后...

例如：

• ＆＃34;在WARN上记录的日志记录代码行实际上会记录在配置了ERROR的部署中吗？＆＃34;表格上写着，没有。
• ＆＃34;记录在WARN的日志记录代码行是否实际登录到配置了DEBUG的部署？＆＃34;表格说“是”。

来自logback documentation 的

：

  

更详细地说，选择规则的工作方式如下。在下表中，垂直标题显示记录请求的级别，由p指定，而水平标题显示记录器的有效级别，由q指定。行（级别请求）和列（有效级别）的交集是基本选择规则产生的布尔值。   

因此，如果其部署的有效日志记录级别小于或等于该代码行请求的，则只会实际记录请求日志记录的代码行>严重程度。

Answer 4

我回答这一点来自基于组件的体系结构，其中组织可能正在运行许多可能相互依赖的组件。在传播失败期间，日志记录级别应该有助于识别哪些组件受影响以及哪些组件是根本原因。

• 错误 - 此组件出现故障，原因被认为是内部的（任何内部未处理的异常，封装依赖性失败...例如数据库，REST示例将是它已收到来自依赖项的4xx错误）。让我（这个组件的维护者）起床。

• 警告 - 此组件发生故障，据信是由依赖组件引起的（REST示例将是依赖项的5xx状态）。让那些组件的维护人员下床。

• INFO - 我们想要获得的任何其他操作员。如果您决定记录快乐路径，那么我建议每个重要操作限制为1个日志消息（例如，每个传入的http请求）。

对于所有日志消息，请务必记录有用的上下文（并优先考虑使消息具有人类可读性/实用性，而不是大量使用“错误代码”）

• DEBUG （及以下） - 根本不应该使用（当然不能在生产中使用）。在开发中，我建议使用TDD和调试的组合（必要时），而不是使用日志语句污染代码。在生产中，上述INFO日志记录与其他指标相结合应该足够了。

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

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

Answer 5

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

1. 错误：应用程序上的严重逻辑错误，如数据库连接超时。那些需要在不久的将来修复bug的事情
2. 警告：不打破问题，但需要注意的事项。就像找不到请求的页面一样
3. 信息：用于函数/方法的第一行，用于显示已调用的过程或步骤已完成，如插入查询已完成
4. log：逻辑信息，类似于if语句的结果
5. debug：与永久监视相关的可变内容