工作总结！日志打印的11条建议

前言

大家好，我是 JavaPub。日志是我们定位问题的得力助手，也是我们团队间协作沟通（甩锅）、明确责任归属（撕B）的利器。没有日志的程序运行起来就如同脱缰的野🐎。打印日志非常重要。今天我们来聊聊日志打印的 N 个好建议～

文章目录

- 前言
- - 选择合适的日志等级
  - 要打印函数的入参、出参
  - 打印日志对象要做判空处理，避免阻断流程
  - 不要使用日志系统的（Log4j、Logback），要使用 Slf4j
  - 对低级别的日志输出，必须进行日志级别开关判断
  - 不要用e.printStackTrace()打印日志
  - 打印全部的异常信息，方便定位问题
  - 不要打印重复日志
  - 日志尽量使用英文
  - 核心业务逻辑，在每个分支首行都打印日志
  - 不要打印无意义的日志（不携带上下文、日志链路 id）

选择合适的日志等级

在开发中我们有常见的四种日志打印等级，debug、info、warn、error，要选择合适的等级打印，不要上来直接 info。

error: 错误日志，指比较严重的问题，会对系统和有业务造成伤害。运维监控重点关注。
warn: 警告日志，不会对系统运行造成大的影响，一般由开发人员关注。
info: 关键日志，为了保留系统运行关键指标，比如函数的入参、出参，时间等信息。
debug: 开发日志，在开发调试阶段，记录对象数据在关键处理步骤中的变化情况、快速定位。

要打印函数的入参、出参

记录日志并不是要把所有信息都记录下来，那日志存储就要大到上天。我们只记录关键有效的日志，有效日志才是 battle 🆚 时杀手锏。

哪些算是有效日志？比如函数的入口处，打印入参，还包括用户唯一标识（uid）、链路标识（traceId） 等。函数出口打印返回值及时间等。

    public String GetName(Request req, Integer id){
        log.debug("method start param: {}", req.UserID);
        
        String name = "JavaPub";
        log.debug("method end result: {}", name);
        return name;
    }

打印日志对象要做判空处理，避免阻断流程

为了打印一行日志，程序写挂了。空指针异常在任何代码中都是最常见的异常之一。

反例：当 book 对象是 NULL 的话，这行日志就会抛空指针异常。

public void doSome(Book book){
    log.info("do do and print log: {}". book.getName());
    // do something...
    ...
}

不要使用日志系统的（Log4j、Logback），要使用 Slf4j

Slf4j 是使用门面模式的日志框架，可以解耦具体的日志实现。可以在不修改代码的情况下，更换底层的日志框架。

正例：

import org.slf4j.Logger; 
import org.slf4j.LoggerFactory;

private static final Logger logger = LoggerFactory.getLogger(JavaPub.class);

对低级别的日志输出，必须进行日志级别开关判断

对于 trace、debug、info 这些比较低的日志级别，必须进行日志级别开关。

正例：

开关判断逻辑通常放在日志工具类中。

public void doSomething(){
    User user = new User(1, "技术自媒体", "JavaPub");
    if (logger.isDebugEnabled()) {
        logger.debug("print debug log. 666 is {}", user.getName());
    }
}

反例：

public void doSth(){
    String name = "JavaPub";
    logger.trace("print debug log" + name);
    logger.debug("print debug log" + name);
    logger.info("print info log" + name);
    // 业务逻辑
    ...
}

当日志级别是 warn 时，以上日志不会打印，但是会执行字符串拼接操作，如果打印值是对象的话，还会执行 toString() 方法，浪费了系统资源，因此建议加上日志开关判断。

不要用e.printStackTrace()打印日志

反例：

public void doSomething(){
    try{
        // 业务代码
        ...
    } catch (Exception e){
        e.printStackTrace();
    }
}

e.printStackTrace() 打印出的日志包含堆栈信息，导致我们的日志信息不规整、增加定位问题的难度。如果使用 ELK 分析日志也会非常困难。
e.printStackTrace() 语句产生的字符串记录的是堆栈信息，如果信息太长太多，字符串常量池所在的内存块没有空间了，即内存满了，系统请求也将被阻塞。

正例：

public void doSomething(){
    try{
        // 业务逻辑
        ...
    } catch (Exception e){
        log.error("程序异常 failed", e);
    }
}

打印全部的异常信息，方便定位问题

反例：

没有打印系统异常 e，无法定位出现了什么类型的异常。

public void doSth(){
    try{
        // 业务逻辑
        ...
    } catch (Exception e){
        log.error("发生了一个异常");
    }
}

不要打印重复日志

在嵌套逻辑代码中打印重复日志，增加系统资源消耗占用。

反例：

public void doSomething(String s){
    log.info("do something and print log: {}", s);
    doSubSomething(s);
}

private void doSubSomething(String s){
    log.info("do sub something and print log: {}", s);
    // 写点业务逻辑
    ...
}

正例：

应该直接删掉或者将为 debug 日志级别。

日志尽量使用英文

反例：

建议：尽量在打印时日志时输出英文，防止中文编码与终端不一致导致打印出现乱码，对排查故障造成感染。

核心业务逻辑，在每个分支首行都打印日志

在编写核心业务逻辑代码时，遇到 if…else 或者 switch 这样的分支条件，在行首打印日志，通过日志可以快速排查定位异常。

public void doSomething(){
    if(user.isVip()){
        log.info("该用户是 JavaPub 会员,Id:{},开始处理会员逻辑",user,getUserId());
        // TODO 会员逻辑
    }else{
        log.info("该用户是非会员,Id:{},开始处理非会员逻辑",user,getUserId())
        // TODO 非会员逻辑
    }
}

不要打印无意义的日志（不携带上下文、日志链路 id）

反例：

不携带任何业务信息的日志，对故障排查意义不大。

public void doSomething(){
    log.info("do something and print log. i am NB");
    // TODO 业务逻辑
    ...
}

正例：

日志一定要携带业务信息相关内容，有利于快速定位问题原因

public void doSomething(Request req, User user){
    log.info("do something and print log, id={}, trace_id={}", user.GetId, req.GetTraceId);
    // TODO 业务逻辑
    ...
}