最简日志打印规范

1. 日志打印组件
2. 日志打印级别
3. 日志打印场景
4. 日志使用方式

个人认为，如果在公司的野蛮生长阶段，一些基础类库不做约束，很可能“埋坑”，形成技术债务，最终为此付出代价。本文讲解一个最简的日志打印规范。
事实上，日志打印规范互联网上已有很多，但大多比较冗长（记不住），也不太契合我们团队（关注点不契合）。

所以，我又造了个轮子，写了个简单易懂、容易记的“最简日志打印规范”，后续随着团队实力的增长，和项目的演进，会逐步增加新的条例。

1. 日志打印组件

日志组件有很多，日志门面的选择有：Slf4j、Apache Commons Logging等。

日志的实现更多，有：log4j、logback、log4j2、Java Util Logging(jul)、Jboss Logging等。

目前，我们使用Slf4j作为日志门面，logback作为日志实现。

2. 日志打印级别

日志的级别有很多，我们一般只用四个。日志级别由低到高DEBUG - INFO - WARN - ERROR。

DEBUG（调试）：开发调试日志。一般来说，在系统实际运行过程中，不会输出该级别的日志。因此，开发人员可以打印任何自己觉得有利于了解系统运行状态的东东。不过很多场景下，过多的DEBUG日志，并不是好事，建议是按照业务逻辑的走向打印。打个比方，打印日志就像读书时划重点，如果导出都是重点，也就失去了重点。
INFO（通知）：INFO日志级别主要用于记录系统运行状态等关联信息。该日志级别，常用于反馈系统当前状态给最终用户。所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。
WARN（警告）：WARN日志常用来表示系统模块发生问题，但并不影响系统运行。此时，进行一些修复性的工作，还能把系统恢复到正常的状态。
ERROR（错误）：此信息输出后，主体系统核心模块正常工作，需要修复才能正常工作。就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。

3. 日志打印场景

在我们的系统中，不同的日志级别的打印场景大致如下：

日志级别	打印场景
DEBUG	调试日志。目前管理相对宽松，我们暂时没有严格要求。
INFO	业务日志。我们用来记录业务的主流程的走向。
WARN	警告日志。一般来说，发生对整个系统没什么影响的异常时，可以打印该级别的日志。
ERROR	错误日志。级别比较高，如果发生一些异常，并且任何时候都需要打印时使用。

4. 日志使用方式

使用的API

1	public static final Logger LOGGER = LoggerFactory.getLogger(MyRealm.class);

我们使用的日志门面是slf4j，使用时应面向接口编程，LOGGER/LoggerFactory应该都是slf4j的API。

严禁直接使用日志实现包。原因大致有两点，第一是面向接口编程更优雅，这点不必说明；第二，举个例子，因为log4j已经几年不更新，老的项目可能使用了log4j，现在想要换用logback或者log4j2，如直接使用log4j的API，不利于选型更换与API的统一（当然，非要用也没关系，有个log4j-over-slf4j的适配器。但接口不统一，总感觉哪里不对劲）。

禁止字符串拼接

例如：

1	LOGGER.debug("当前用户是:" + user + ",传入参数是:" + userId);

严禁使用字符串拼接的方式打印日志，可读性、可维护性都比较差。

建议的写法如下：

1	LOGGER.debug("当前用户是:{},传入参数是:{},返回值是:{},用户信息:{}", a,b new Object[]{token, userId, userInfo, authcInfo});

因为我们使用的是Slf4j，Slf4j有占位符填充的功能。多个占位符可放在Object数组中。

无需使用级别判断

不优雅示例：

1
2
3

if (LOGGER.isDebugEnabled()) {
	LOGGER.debug("当前用户是{}", token);
}

以前，为了性能，我们常常在打印日志之前判断一下。

使用Slf4j后，我们可以写成如下形式就OK了。

1	LOGGER.debug("当前用户是{}", token);

当然，如果依然使用字符串拼接的方式，还是得判断一下级别的。

1. 日志打印组件

2. 日志打印级别

3. 日志打印场景

4. 日志使用方式

相关文章