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

前言

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

选择合适的日志等级

在开发中我们有常见的四种日志打印等级,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 业务逻辑
    ...
}

如何打印日志呢?总的来说不要让你的程序在黑盒总运行,打印关键信息、保证在出现异常时通过日志快速定位到那里就可以啦。

热门相关:我写的书实在太毒了   九星毒奶   美女总裁之贴身高手   我真的是正派   重生全能悍妻:张狂大小姐