1. 利用门面模式的日志框架，有利于维护和各个类的日志处理惩罚方法统一。
2. 实现方法统一利用: Logback框架

打日志的正确方法

什么时候应该打日志

1. 当你碰着问题的时候，只能通过debug成果来确定问题，你应该思量打日志，精采的系统，是可以通过日志举办问题定为的。
2. 当你遇到if…else 可能 switch这样的分支时，要在分支的首行打印日志，用来确定进入了哪个分支
3. 常常以成果为焦点举办开拓，你应该在提交接码前，可以确定通过日志可以看到整个流程

根基名目

必需利用参数化信息的方法:

logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);

对付debug日志，必需判定是否为debug级别后，才举办利用:

if (logger.isDebugEnabled()) {
    logger.debug("Processing trade with id: " +id + " symbol: " + symbol);
}

不要举办字符串拼接,那样会发生许多String工具，占用空间，影响机能。
反例(不要这么做):

logger.debug("Processing trade with id: " + id + " symbol: " + symbol);

利用[]举办参数变量断绝

如有参数变量，应该写成如下写法:

logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);

这样的名目写法，可读性更好，对付排盘查题更有辅佐。

差异级此外利用

ERROR:

根基观念

影响到措施正常运行、当前请求正常运行的异常环境:

1. 打开设置文件失败
2. 所有第三方对接的异常(包罗第三方返回错误码)
3. 所有影响成果利用的异常，包罗:SQLException和除了业务异常之外的所有异常(RuntimeException和Exception)

不该该呈现的环境:

1. 好比要利用Azure传图片，可是Azure未响应

假如有Throwable信息，需要记录完成的仓库信息:

log.error("获取用户[{}]的用户信息时堕落",userName,e);

说明

1. 假如举办了抛出异常操纵，昆山软件开发，请不要记录error日志，由最终处理惩罚方举办处理惩罚：

反例(不要这么做):

try{
    ....
}catch(Exception ex){
  String errorMessage=String.format("Error while reading information of user [%s]",userName);
  logger.error(errorMessage,ex);
  throw new UserServiceException(errorMessage,ex);
}

WARN

根基观念

不该该呈现可是不影响措施、当前请求正常运行的异常环境:

1. 有容错机制的时候呈现的错误环境
2. 找不到设置文件，可是系统能自动建设设置文件

即将靠近临界值的时候，劳务派遣管理系统，譬喻：

1. 缓存池占用到达告诫线

业务异常的记录,好比:

1. 当接口抛出业务异常时，昆山软件开发，应该记录此异常

INFO:

根基观念

系统运行信息

1. Service要领中对付系统/业务状态的改观
2. 主要逻辑中的分步调

外部接口部门

1. 客户端请求参数(REST/WS)
2. 挪用第三方时的挪用参数和挪用功效

说明

1. 并不是所有的service都举办进出口解决记录,单一、简朴service是没有意义的(job除外,job需要记录开始和竣事,)。
   反例(不要这么做):

   public List listByBaseType(Integer baseTypeId) {
   
       log.info("开始查询基地");
   BaseExample ex=new BaseExample();
   BaseExample.Criteria ctr = ex.createCriteria();
   ctr.andIsDeleteEqualTo(IsDelete.USE.getValue());
   Optionals.doIfPresent(baseTypeId, ctr::andBaseTypeIdEqualTo);
       log.info("查询基地竣事");
   return baseRepository.selectByExample(ex);
   }

2. 对付巨大的业务逻辑，需要举办日志解决，以及埋点记录，好比电商系统中的下订单逻辑，以及OrderAction操纵(业务状态改观)。
3. 对付整个系统的提供出的接口(REST/WS)，利用info记录入参
4. 假如所有的service为SOA架构，那么可以当作是一个外部接口提供方，那么必需记录入参。
5. 挪用其他第三方处事时，所有的出参和入参是必需要记录的(因为你很难追溯第三方模块产生的问题)

DEBUG

根基观念

1. 可以填写所有的想知道的相关信息(但不代表可以随便写，debug信息要有意义,最好有相关参数)
2. 出产情况需要封锁DEBUG信息
3. 假如在出产环境下需要开启DEBUG,需要利用开关举办打点，不能一直开启。

说明