Java 日志记录规则

规则一：日志是面向读者的

我们不应该让无价值的信息使日志文件变得乱糟糟，比如说完整打印所有的实体字段。

通常，实体名字和其逻辑关键字足以识别在表格中的一条记录了。

规则二：匹配日志等级和执行环境

在 Java 系统中提供的所有日志管理工具和引擎都有日志等级（ERROR、INFO……）的概念，这将有可能过滤掉等级过低的消息。

例如，Java util logging 使用如下的等级：SEVERE、WARN、INFO、FINE、FINER、FINEST（+ CONFIG 和 OFF）。相反，两个最受欢迎的日志管理工具， Apache Commons Logging 和 SLFJ 更倾向于如下的等级：FATAL、ERROR、WARN、INFO、DEBUG、TRACE。

日志过滤等级则需要取决于代码的开发阶段：成品与仍处在测试、集成环境下的代码日志等级就不能相同。

更具体的来说，日志等级也应该参考代码的归属情况。

一般而言，我们自己的应用程序代码应该比使用的任何第三方开发库拥有更详细的日志记录。

比如说，Apache 的通用调试消息出现在我们的日志文件中，就没有多大意义。

我通常像这样配置日志记录：

成品阶段： 我的代码是 INFO 等级，第三方库是 WARN。

测试、集成阶段：我的代码是 DEBUG 等级，第三方库是 WARN（或者如果需要的话是 INFO）。

开发阶段：任何有意义的信息。

注意：个人而言，我不建议使用 TRACE/FINEST 等级（我并不是唯一持这种观点的人，可以参考 这里 的例子）。

我并没有发现 DEBUG 和 TRACE 有多大的区别，而年轻团队的成员常常苦恼于到底是使用 DEBUG 还是 TRACE 。

根据 KISS 原则，我建议只使用 RROR、WARN、INFO 和 DEBUG 等级。

规则三：提交前去除编码帮助日志

一旦你已经完成开发工作，在将代码提交到使用中的 SCM 系统（git、svn……）之前，要去除所有临时的和不必要的日志消息。

这条规则并不是要求去除所有的 DEBUG 消息，只是针对那些在应用程序完成和发布后就没有意义的消息，或者是说当我们有理由相信应用程序能正确运行时就失去意义的那些消息。

规则四：log DEBUG消息之前检查日志等级

根据第2条规则，在产品日志中，我们只会显示 ERROR、WARN、INFO 等级的消息，但是在代码中我们也可以使用一些不会影响产品运行的 DEBUG 消息。

if ( LOGGER.isDebugEnabled((){

 LOGGER.debug (…….)

 }

每次你想要 log 一个 DEBUG 消息时（在使用了规则3后的留下的所有消息），需要在前面添加一个检查来明确是否启用了 DEBUG 日志：

if ( LOGGER.isDebugEnabled((){

 LOGGER.debug (…….)

 }

这种做法可以阻止代码去创建日志消息和调用 logger，提高产品运行程序的效率。

规则五：了解你的 logger

我们使用 logger 方法的方式可能会带来巨大的开销：

创建消息字符串

组织包含在消息字符串中的数据

我们应该查阅所选择的日志管理工具、引擎的 javadoc 文档，了解使用它们 logger 的最有效的方法。