最简日志打印规范

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

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

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);

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

上一篇