我在我当前的项目中使用logback .
它提供六个级别的日志记录：TRACE DEBUG INFO WARN ERROR OFF
我正在寻找一个经验法则来确定常见活动的日志级别 . 例如，如果线程被锁定，则应将日志消息设置为调试级别或信息级别 . 或者，如果正在使用套接字，则应在调试级别还是跟踪级别记录其特定标识 .
我将欣赏每个日志记录级别的更多示例的答案 .
我主要 Build 大规模，高可用性类型的系统，所以我的答案偏向于从 生产环境 支持的角度来看待它;那说，我们大致分配如下：
error ：系统遇险，客户可能受到影响（或即将成为），修复可能需要人为干预 . "2AM rule"适用于此 - 如果您正在通话，如果发生这种情况，您是否希望在凌晨2点被唤醒？如果是，则将其记录为"error" .
warn ：发生了意外的技术或商业事件，客户可能受到影响，但可能不需要立即进行人为干预 . 随叫随到的人不会立即被呼叫，但支持人员会希望尽快查看这些问题，以了解其影响 . 基本上任何需要跟踪但可能不需要立即干预的问题 .
info ：如果我们需要对问题进行法医分析，我们希望大量查看 . 系统生命周期事件（系统启动，停止）转到此处 . "Session"生命周期事件（登录，注销等）转到此处 . 还应考虑重要的边界事件（例如数据库调用，远程API调用） . 典型的业务异常可以在这里（例如，由于凭证错误导致登录失败） . 您认为在大批量 生产环境 中需要看到的任何其他事件都会在此处进行 .
debug ：几乎所有不能使"info"切割的内容...任何有助于跟踪系统流程并隔离问题的消息，尤其是在开发和QA阶段 . 我们使用"debug"级别日志来进入/退出大多数非平凡的方法，并在方法内标记有趣的事件和决策点 .
trace ：我们通常希望即使在正常开发期间也能启用 . 示例包括转储完整的对象层次结构，在大循环的每次迭代期间记录某些状态等 .
选择正确的日志级别或者更重要的是确保日志有意义并具有所需的上下文 . 例如，您几乎总是希望在日志中包含线程ID，以便您可以根据需要跟踪单个线程 . 您可能还希望使用一种机制将业务信息（例如用户ID）与线程相关联，以便记录它 . 在日志消息中，您需要包含足够的信息以确保消息可以操作 . 像“FileNotFound异常捕获”这样的日志不是很有帮助 . 更好的消息是“尝试打开配置文件时捕获到FileNotFound异常：/usr/local/app/somefile.txt.userId = 12344 . ”
还有一些很好的日志记录指南...例如，这是一个来自JCL (Jakarta Commons Logging)的编辑片段：
错误 - 其他运行时错误或意外情况 . 期望这些在状态控制台上立即可见 . warn - 使用不推荐使用的API，API的使用不当，“几乎”错误，其他不期望或意外的运行时情况，但不一定“错误” . 期望这些在状态控制台上立即可见 . info - 有趣的运行时事件（启动/关闭） . 期望这些在控制台上立即可见，所以保守并保持最低限度 . debug - 有关通过系统的流量的详细信息 . 期望这些只写入日志 . 跟踪 - 更详细的信息 . 期望这些只写入日志 .
我的方法，我认为更多来自开发而不是运营的观点，是：
Error 表示无法完成某项任务的执行;一封电子邮件无法呈现，某些数据无法存储到数据库中，就像这样 . 有些东西肯定出错了 .
Warning 表示发生了意外情况，但执行可能会继续，可能是在降级模式下;配置文件丢失但使用了默认值，价格计算为负值，因此它被限制为零等 . 有些东西是不对的，但它还没有正确错误 - 警告通常表明很快就会出现错误 .
Info 意味着正常但重要的事情发生了;系统启动，系统停止，每日库存更新工作运行等等 . 不应该只读't be a continual torrent of these, otherwise there'太多了 .
Debug 意味着发生了正常和微不足道的事情;一个新用户来到该网站，一个页面被渲染，一个订单，一个价格被更新 . 这是从信息中排除的东西，因为它会有太多 .
Trace 是我从未实际使用过的东西 .
这也可能是切向帮助，以了解在给定部署配置的有效日志记录级别的情况下，某个级别的日志记录请求（来自代码）是否会导致实际记录 . 从此处的其他Answers确定您希望配置部署的有效级别，然后参考此处以查看代码中是否实际记录了特定的日志记录请求，然后...
举些例子：
"Will a logging code line that logs at WARN actually get logged on my deployment configured with ERROR?"表说，不 .
"Will a logging code line that logs at WARN actually get logged on my deployment configured with DEBUG?"表说，是的 .
来自logback documentation：
以更加图形化的方式，这是选择规则的工作方式 . 在下表中，垂直 Headers 显示记录请求的级别，由p指定，而水平 Headers 显示 Logger 的有效级别，由q指定 . 行（级别请求）和列（有效级别）的交集是基本选择规则产生的布尔值 .
因此，如果其部署的有效日志记录级别小于或等于该代码行的请求严重性级别，则实际上会记录请求日志记录的代码行 .
我回答这个问题来自基于组件的体系结构，组织可能正在运行许多可能相互依赖的组件 . 在传播失败期间，日志记录级别应有助于识别哪些组件受影响以及哪些组件是根本原因 .
ERROR - 该组件发生故障，原因被认为是内部的（任何内部未处理的异常，封装依赖的失败......例如数据库，REST示例将从依赖中收到4xx错误） . 让我（这个组件的维护者）起床 .
WARN - 此组件发生故障，据信是由依赖组件引起的（REST示例将是依赖项的5xx状态） . 让这个组件的维护者下床 .
INFO - 我们想要的其他任何操作员 . 如果您决定记录快乐路径，那么我建议每个重要操作限制为1个日志消息（例如，每个传入的http请求） .
对于所有日志消息，请务必记录有用的上下文（并优先考虑使消息具有人类可读性/有用性，而不是让大量的“错误代码”）
可视化上述日志记录级别的一种好方法是为每个组件设想一组监视屏幕 . 当一切运行良好时它们是绿色的，如果一个组件记录一个警告，那么它将变为橙色（琥珀色），如果有任何记录ERROR，那么它将变为红色 .
如果发生事故，您应该有一个（根本原因）组件变为红色，所有受影响的组件应该变为橙色/琥珀色 .
与其他答案没有什么不同，我的框架几乎具有相同的级别：
错误：应用程序上的严重逻辑错误，如数据库连接超时 . 需要在不久的将来修复bug的事情
警告：不打破问题，但需要注意的事项 . 就像找不到请求的页面一样
信息：在函数/方法的第一行中使用，以显示已调用的过程或步骤一切正常，如插入查询完成
log：逻辑信息，就像if语句的结果一样
debug：与永久监视相关的变量内容
5 回答
我主要 Build 大规模，高可用性类型的系统，所以我的答案偏向于从 生产环境 支持的角度来看待它;那说，我们大致分配如下：
error ：系统遇险，客户可能受到影响（或即将成为），修复可能需要人为干预 . "2AM rule"适用于此 - 如果您正在通话，如果发生这种情况，您是否希望在凌晨2点被唤醒？如果是，则将其记录为"error" .
warn ：发生了意外的技术或商业事件，客户可能受到影响，但可能不需要立即进行人为干预 . 随叫随到的人不会立即被呼叫，但支持人员会希望尽快查看这些问题，以了解其影响 . 基本上任何需要跟踪但可能不需要立即干预的问题 .
info ：如果我们需要对问题进行法医分析，我们希望大量查看 . 系统生命周期事件（系统启动，停止）转到此处 . "Session"生命周期事件（登录，注销等）转到此处 . 还应考虑重要的边界事件（例如数据库调用，远程API调用） . 典型的业务异常可以在这里（例如，由于凭证错误导致登录失败） . 您认为在大批量 生产环境 中需要看到的任何其他事件都会在此处进行 .
debug ：几乎所有不能使"info"切割的内容...任何有助于跟踪系统流程并隔离问题的消息，尤其是在开发和QA阶段 . 我们使用"debug"级别日志来进入/退出大多数非平凡的方法，并在方法内标记有趣的事件和决策点 .
trace ：我们通常希望即使在正常开发期间也能启用 . 示例包括转储完整的对象层次结构，在大循环的每次迭代期间记录某些状态等 .
选择正确的日志级别或者更重要的是确保日志有意义并具有所需的上下文 . 例如，您几乎总是希望在日志中包含线程ID，以便您可以根据需要跟踪单个线程 . 您可能还希望使用一种机制将业务信息（例如用户ID）与线程相关联，以便记录它 . 在日志消息中，您需要包含足够的信息以确保消息可以操作 . 像“FileNotFound异常捕获”这样的日志不是很有帮助 . 更好的消息是“尝试打开配置文件时捕获到FileNotFound异常：/usr/local/app/somefile.txt.userId = 12344 . ”
还有一些很好的日志记录指南...例如，这是一个来自JCL (Jakarta Commons Logging)的编辑片段：
我的方法，我认为更多来自开发而不是运营的观点，是：
Error 表示无法完成某项任务的执行;一封电子邮件无法呈现，某些数据无法存储到数据库中，就像这样 . 有些东西肯定出错了 .
Warning 表示发生了意外情况，但执行可能会继续，可能是在降级模式下;配置文件丢失但使用了默认值，价格计算为负值，因此它被限制为零等 . 有些东西是不对的，但它还没有正确错误 - 警告通常表明很快就会出现错误 .
Info 意味着正常但重要的事情发生了;系统启动，系统停止，每日库存更新工作运行等等 . 不应该只读't be a continual torrent of these, otherwise there'太多了 .
Debug 意味着发生了正常和微不足道的事情;一个新用户来到该网站，一个页面被渲染，一个订单，一个价格被更新 . 这是从信息中排除的东西，因为它会有太多 .
Trace 是我从未实际使用过的东西 .
这也可能是切向帮助，以了解在给定部署配置的有效日志记录级别的情况下，某个级别的日志记录请求（来自代码）是否会导致实际记录 . 从此处的其他Answers确定您希望配置部署的有效级别，然后参考此处以查看代码中是否实际记录了特定的日志记录请求，然后...
举些例子：
"Will a logging code line that logs at WARN actually get logged on my deployment configured with ERROR?"表说，不 .
"Will a logging code line that logs at WARN actually get logged on my deployment configured with DEBUG?"表说，是的 .
来自logback documentation：
因此，如果其部署的有效日志记录级别小于或等于该代码行的请求严重性级别，则实际上会记录请求日志记录的代码行 .
我回答这个问题来自基于组件的体系结构，组织可能正在运行许多可能相互依赖的组件 . 在传播失败期间，日志记录级别应有助于识别哪些组件受影响以及哪些组件是根本原因 .
ERROR - 该组件发生故障，原因被认为是内部的（任何内部未处理的异常，封装依赖的失败......例如数据库，REST示例将从依赖中收到4xx错误） . 让我（这个组件的维护者）起床 .
WARN - 此组件发生故障，据信是由依赖组件引起的（REST示例将是依赖项的5xx状态） . 让这个组件的维护者下床 .
INFO - 我们想要的其他任何操作员 . 如果您决定记录快乐路径，那么我建议每个重要操作限制为1个日志消息（例如，每个传入的http请求） .
对于所有日志消息，请务必记录有用的上下文（并优先考虑使消息具有人类可读性/有用性，而不是让大量的“错误代码”）
可视化上述日志记录级别的一种好方法是为每个组件设想一组监视屏幕 . 当一切运行良好时它们是绿色的，如果一个组件记录一个警告，那么它将变为橙色（琥珀色），如果有任何记录ERROR，那么它将变为红色 .
如果发生事故，您应该有一个（根本原因）组件变为红色，所有受影响的组件应该变为橙色/琥珀色 .
与其他答案没有什么不同，我的框架几乎具有相同的级别：
错误：应用程序上的严重逻辑错误，如数据库连接超时 . 需要在不久的将来修复bug的事情
警告：不打破问题，但需要注意的事项 . 就像找不到请求的页面一样
信息：在函数/方法的第一行中使用，以显示已调用的过程或步骤一切正常，如插入查询完成
log：逻辑信息，就像if语句的结果一样
debug：与永久监视相关的变量内容