logging级别 – Logback – 经验法则分配日志级别
我在当前项目中使用了logback 。
它提供六个级别的日志logging：TRACE DEBUG INFO WARN ERROR OFF
我正在寻找经验法则来确定常见活动的日志级别。 例如，如果线程被locking，日志消息应该设置为debugging级别还是信息级别。 或者，如果套接字正在使用，它的特定ID是否应该logging在debugging级别或跟踪级别。
我会感谢每个日志logging级别的更多示例的答案。
我主要是build立大规模，高可用性的系统，所以我的答案是偏向于从生产支持的angular度来看待它; 说，我们大致分配如下：
-
错误 ：系统处于困境，客户可能正在受到影响（或即将出现），修复可能需要人为干预。 “2AM规则”在这里适用 – 如果你正在通话，如果这种情况发生，你想在凌晨2点醒来吗？ 如果是，则logging为“错误”。
-
警告 ：意外的技术或商业事件发生，客户可能会受到影响，但可能不需要立即进行人为干预。 随时待命的人不会立即被呼叫，但支持人员将尽快审查这些问题，以了解影响是什么。 基本上任何需要跟踪的问题，但可能不需要立即干预。
-
信息 ：我们希望看到大量的情况下，我们需要从法律上分析一个问题。 系统生命周期事件（系统启动，停止）到这里。 “会话”生命周期事件（login，注销等）在这里。 重要的边界事件也应该被考虑（例如数据库调用，远程API调用）。 典型的业务exception可以在这里（例如，由于证书不好而导致login失败）。 任何其他你认为需要大批量生产的活动都会在这里进行。
-
debugging ：几乎所有不会使“信息”被切断的信息…任何有助于跟踪系统stream程和隔离问题的消息，特别是在开发和QA阶段。 我们使用“debugging”级别的日志进入/退出大多数不平凡的方法，并在方法内标记有趣的事件和决策点。
-
跟踪 ：我们不经常使用这种方法，但是这对于非常详细和可能的高容量日志，即使在正常开发过程中，您通常也不需要启用。 例子包括转储完整的对象层次结构，在大循环的每次迭代中logging某个状态等。
比select正确的日志级别更重要的是确保日志有意义并具有所需的上下文。 例如，您几乎总是希望将线程ID包含在日志中，以便在需要时可以跟踪单个线程。 您也可能想要使用一种机制将业务信息（例如用户ID）关联到线程，以便将其logging下来。 在你的日志消息中，你需要包含足够的信息来确保消息可以被操作。 像“发现FileNotFoundexception”的日志不是很有帮助。 更好的消息是“尝试打开configuration文件时捕获到FileNotFoundexception：/usr/local/app/somefile.txt。userId = 12344”。
还有一些很好的日志logging指南…例如，这里是从JCL（雅加达共享日志logging）编辑片段：
- 错误 – 其他运行时错误或意外情况。 期望这些在状态控制台上立即可见。
- 警告 – 使用已弃用的API，API使用不当，“几乎”错误，其他运行时情况不理想或意外，但不一定是“错误的”。 期望这些在状态控制台上立即可见。
- info – 有趣的运行时事件（启动/closures）。 期望这些在控制台上立即可见，所以要保守并保持最低限度。
- debugging – 通过系统的stream量的详细信息。 期望这些只写入日志。
- 跟踪 – 更详细的信息。 期望这些只写入日志。
我认为我的方法更多地来自于一个发展，而不是一个运作的angular度：
- 错误意味着某个任务的执行无法完成; 一个电子邮件不能被发送，一个页面不能被渲染，一些数据不能被存储到数据库，类似的东西。 有些事情确实发生了错误。
- 警告意味着意想不到的事情发生了，但是执行可能会继续下去，也许在退化的模式下; 一个configuration文件丢失，但使用了默认值，价格被计算为负值，所以它被限制为零等等。有些东西是不正确的，但是它还没有正确地错误 – 警告往往是一个信号一个错误很快。
- 信息意味着正常但有意义的事情发生; 系统启动，系统停止，日常库存更新工作等等。不应该有这些不断的洪stream，否则就太多了。
- debugging意味着发生了一些正常和微不足道的事情; 一位新用户来到网站，一个页面被渲染，一个订单被采取，一个价格被更新。 这是从信息排除的东西，因为它会太多了。
- 跟踪是我从来没有实际使用的东西。
我从基于组件的体系结构回答这个问题，一个组织可能运行着许多可能相互依赖的组件。 在传播失败期间，日志logging级别应该有助于识别哪些组件受到影响，哪些是根本原因。
-
错误 – 这个组件失败了，原因被认为是内部的（任何内部的，未处理的exception，封装的依赖失败…例如数据库，REST的例子是它从一个依赖收到4xx错误）。 让我（这个组件的维护者）起床。
-
警告 – 这个组件有一个相信是由一个依赖组件引起的故障（REST示例将是一个依赖的5xx状态）。 从床上获得该组件的维护者。
-
信息 – 任何我们想要得到一个操作员。 如果你决定logging快乐的path，那么我build议每个重要的操作（例如每个传入的http请求）限制为1个日志消息。
对于所有的日志消息，一定要logging有用的上下文（并优先使消息人类可读/有用，而不是有大量的“错误代码”）
- debugging （和下面） – 不应该使用（当然不是在生产）。 在开发中，我会build议使用TDD和debugging（必要时）的组合，而不是用日志语句污染代码。 在生产中，上面的INFO日志logging，结合其他指标应该是足够的。
想象以上日志logging级别的一个好方法是想象每个组件的一组监视屏幕。 当所有运行良好时，它们都是绿色的，如果某个组件logging了警告，那么如果有任何事情logging了一个错误，它将变成橙色（琥珀色），然后它将变成红色。
在发生事件时，您应该有一个（根本原因）组件变为红色，并且所有受影响的组件都应变为橙色/琥珀色。
其他答案没有什么不同，我的框架几乎相同的水平：
- 错误：应用程序上的关键逻辑错误，如数据库连接超时。 事情要求在不久的将来修复错误
- 警告：没有突破的问题，但要注意的东西。 像找不到请求的页面
- 信息：用于函数/方法的第一行，显示一个已经被调用的过程或者一个好的步骤，就像插入查询完成一样
- 日志：逻辑信息，如if语句的结果
- debugging：相关的可变内容被永久观看
这也可能会帮助理解，如果某个级别的日志logging请求 （来自代码）会导致它实际上被logging，因为部署configuration的日志级别是有效的 。 从这里的其他答案决定什么样的有效级别你想configuration你的部署，然后引用这个来看你的代码中的特定日志logging请求是否会被logging下来然后…
例如 ：
- “将logging在WARN的日志logging代码行实际上login我的部署configuration错误？ 桌子说，没有。
- “logging在WARN的日志logging代码行是否会实际login我的部署configurationDEBUG？ 桌子说，是的。
来自logback文档 ：
更为直观地说，这里是select规则的工作原理。 在下表中，垂直标题显示logging请求的级别，由p指定，而水平标题显示logging器的有效级别，由q指定。 行（级别请求）和列（有效级别）的交集是基本select规则产生的布尔值。
因此，如果其部署的有效日志logging级别小于或等于该代码行所要求的严重级别，那么请求日志logging的代码行将仅实际得到logging。
