日志级别 - Logback - 分配日志级别的经验法则 [英] Logging levels - Logback - rule-of-thumb to assign log levels

问题描述

我在当前项目中使用 logback.

I'm using logback in my current project.

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

It offers six levels of logging: TRACE DEBUG INFO WARN ERROR OFF

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

I'm looking for a rule of thumb to determine the log level for common activities. For instance, if a thread is locked, should the log message be set to the debug level or the info level. Or if a socket is being used, should its specific id be logged at the debug level or the trace level.

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

I will appreciate answers with more examples for each logging level.

推荐答案

我主要构建大规模、高可用性类型的系统，所以我的回答偏向于从生产支持的角度看待它；也就是说，我们大致分配如下:

I mostly build large scale, high availability type systems, so my answer is biased towards looking at it from a production support standpoint; that said, we assign roughly as follows:

• 错误:系统陷入困境，客户可能受到影响(或即将受到影响)，修复可能需要人工干预.凌晨 2 点规则"适用于此处——如果您正在待命，如果发生这种情况，您是否希望在凌晨 2 点被叫醒?如果是，则将其记录为错误".

• error: the system is in distress, customers are probably being affected (or will soon be) and the fix probably requires human intervention. The "2AM rule" applies here- if you're on call, do you want to be woken up at 2AM if this condition happens? If yes, then log it as "error".

警告:发生了意外的技术或业务事件，客户可能会受到影响，但可能不需要立即人工干预.不会立即呼叫随叫随到的人员，但支持人员会希望尽快审查这些问题以了解影响是什么.基本上任何需要跟踪但可能不需要立即干预的问题.

warn: an unexpected technical or business event happened, customers may be affected, but probably no immediate human intervention is required. On call people won't be called immediately, but support personnel will want to review these issues asap to understand what the impact is. Basically any issue that needs to be tracked but may not require immediate intervention.

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

info: things we want to see at high volume in case we need to forensically analyze an issue. System lifecycle events (system start, stop) go here. "Session" lifecycle events (login, logout, etc.) go here. Significant boundary events should be considered as well (e.g. database calls, remote API calls). Typical business exceptions can go here (e.g. login failed due to bad credentials). Any other event you think you'll need to see in production at high volume goes here.

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

debug: just about everything that doesn't make the "info" cut... any message that is helpful in tracking the flow through the system and isolating issues, especially during the development and QA phases. We use "debug" level logs for entry/exit of most non-trivial methods and marking interesting events and decision points inside methods.

trace:我们不经常使用它，但这将用于非常详细和潜在的大量日志，即使在正常开发过程中，您通常也不希望启用这些日志.示例包括转储完整的对象层次结构、在大型循环的每次迭代期间记录某些状态等.

trace: we don't use this often, but this would be for extremely detailed and potentially high volume logs that you don't typically want enabled even during normal development. Examples include dumping a full object hierarchy, logging some state during every iteration of a large loop, etc.

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

As or more important than choosing the right log levels is ensuring that the logs are meaningful and have the needed context. For example, you'll almost always want to include the thread ID in the logs so you can follow a single thread if needed. You may also want to employ a mechanism to associate business info (e.g. user ID) to the thread so it gets logged as well. In your log message, you'll want to include enough info to ensure the message can be actionable. A log like " FileNotFound exception caught" is not very helpful. A better message is "FileNotFound exception caught while attempting to open config file: /usr/local/app/somefile.txt. userId=12344."

还有一些很好的日志记录指南......例如，这里有一个来自 JCL(Jakarta Commons Logging):

There are also a number of good logging guides out there... for example, here's an edited snippet from JCL (Jakarta Commons Logging):

• error - 其他运行时错误或意外情况.期望这些在状态控制台上立即可见.
• warn - 使用已弃用的 API、API 使用不当、几乎"错误、其他不受欢迎或意外的运行时情况，但不是必然错误".希望这些可以立即在状态控制台.
• info - 有趣的运行时事件(启动/关闭).希望这些可以立即在控制台上看到，所以要保守并保持最低限度.
• 调试 - 有关通过系统的流程的详细信息.期望这些仅写入日志.
• trace - 更详细的信息.预计这些只会写入日志.

这篇关于日志级别 - Logback - 分配日志级别的经验法则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！