日志记录级别

本文介绍了日志记录级别-Logback-分配日志级别的经验法则的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我在当前项目中使用 logback .

它提供了六个日志记录级别: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:

• 错误:系统处于困境中，客户可能受到影响(或将很快受到影响)，并且此修复程序可能需要人工干预. "2AM规则"适用于此-如果您正在通话中，如果发生这种情况，是否要在2AM醒来?如果是，则将其记录为错误".

• 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: 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(雅加达公共记录):

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

• 错误-其他运行时错误或意外情况.希望它们在状态控制台上立即可见.
• 警告-使用已弃用的API，API使用不当，几乎"错误，其他不希望发生或无法预期的运行时情况，但并非如此 必然是错误的".希望这些内容可以立即在 状态控制台.
• info-有趣的运行时事件(启动/关闭).希望这些内容在控制台上立即可见，因此请保持保守并保持 最低限度.
• 调试-有关通过系统的流的详细信息.期望这些仅写入日志.
• trace-更详细的信息.希望这些内容只能写到日志中.
• error - Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console.
• warn - Use of deprecated APIs, poor use of API, 'almost' errors, other runtime situations that are undesirable or unexpected, but not necessarily "wrong". Expect these to be immediately visible on a status console.
• info - Interesting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum.
• debug - detailed information on the flow through the system. Expect these to be written to logs only.
• trace - more detailed information. Expect these to be written to logs only.