记录级别

 

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

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

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

我会很感激每个日志级别的更多示例。

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

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

  • 警告 ：发生意外的技术或商业事件，客户可能会受到影响，但可能不需要立即进行人为干预。 电话会议中不会立即呼叫人员，但支持人员会尽快检查这些问题，以了解影响是什么。 基本上任何需要跟踪的问题，但可能不需要立即干预。

  • info ：我们希望大量看到的情况，以防我们需要从法律上分析问题。 系统生命周期事件（系统启动，停止）到这里。 “会话”生命周期事件（登录，注销等）到这里。 重要的边界事件也应该被考虑（例如数据库调用，远程API调用）。 典型的业务异常可以在这里进行（例如，由于凭证错误导致登录失败）。 任何其他你认为需要大批量生产的活动都会在这里进行。

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

  • 跟踪 ：我们不经常使用它，但是这对于非常详细的和可能的高容量日志，即使在正常开发过程中，您通常不希望启用它们。 例子包括转储完整的对象层次结构，在大循环的每次迭代中记录某些状态等。

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

    还有一些很好的日志记录指南......例如，这里有一个来自JCL（Jakarta Commons Logging）的编辑片段：

  • 错误 - 其他运行时错误或意外情况。 预计这些在状态控制台上立即可见。
  • 警告 - 使用已弃用的API，API使用不当，“几乎”错误，其他运行时情况不理想或意外，但不一定是“错误的”。 预计这些在状态控制台上立即可见。
  • info - 有趣的运行时事件（启动/关闭）。 期望这些在控制台上立即可见，所以要保守并保持最低限度。
  • 调试 - 关于通过系统的流量的详细信息。 期望这些只写入日志。
  • 跟踪 - 更详细的信息。 期望这些只写入日志。

    • 我认为我的方法更多地来自发展而不是运营角度，即：

  • 错误意味着某些任务的执行无法完成; 无法发送电子邮件，页面无法呈现，有些数据无法存储到数据库，类似的。 有些事情确实发生了错误。
  • 警告意味着意想不到的事情发生了，但是执行可能会继续下去，也许在退化模式下; 一个配置文件丢失了，但是使用了默认值，价格被计算为负数，所以它被限制为零等等。有些东西是不正确的，但它还没有正确地错误 - 警告通常表明将会有很快就会出现错误。
  • 信息意味着发生了正常但重要的事情; 系统启动，系统停止运行，日常库存更新作业运行等等。不应该有这些持续的洪流，否则就太多了。
  • 调试意味着发生了一些正常和微不足道的事情; 一位新用户来到该网站，一个页面被渲染，一个订单被采纳，价格被更新。 这是从信息中排除的东西，因为它会太多。
  • 追踪是我从未实际使用过的东西。

    • 我回答了这个来自基于组件的架构，一个组织可能运行许多可能相互依赖的组件。 在传播失败期间，日志记录级别应该有助于识别哪些组件受到影响，哪些是根本原因。

  • 错误 - 这个组件发生了故障，原因被认为是内部的（任何内部的，未处理的异常，封装依赖的失败......例如数据库，REST的例子就是它已经从依赖中收到4xx错误）。 让我（这个组件的维护者）起床。

  • WARN - 这个组件有一个被认为是由依赖组件引起的失败（REST示例将是来自依赖项的5xx状态）。 将该组件的维护人员从床上拿走。

  • 信息 - 任何我们想要获得给操作员的信息。 如果你决定登录开心路径，那么我建议限制每个重要操作1个日志消息（例如每个传入的http请求）。

    • 对于所有的日志消息，一定要记录有用的上下文（并且优先考虑使消息成为人类可读/有用的，而不是让大量的“错误代码”）

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

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

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

    链接地址: http://www.djcxy.com/p/36825.html

    上一篇: Logging levels

    下一篇: Logback native VS Logback via SLF4J