slf4j的正确使用

头两天领导分配个任务是要把项目中所有try catch里的异常处理收集到elk中，由于之前的处理方式五花八门，就集中处理了下， 事后还被批评了。

不是所有的异常信息都需要被记录到log中

使用SLF4J

1. 使用门面模式的日志框架，有利于维护各个类的日志处理方式的统一。
2. 实现方式的统一使用，使用logback框架。

什么时候应该打日志？

1. 当你遇到问题的时候，只能通过debug功能来确定问题，你应该考虑打日志，良好的系统，是可以通过日志来定位问题所在的。
2. 当你碰到if..else或者switch这样的分支的时候，可以在首行打印日志，用来确定进入了那个分支。
3. 经常以功能为核心进行开发的时候，可以在提交代码前，通过日志看到整个流程。

基本格式

必须使用参数化信息的方式：

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

对于debug日志，必须判断是否为debug级别后，才进行使用。

不过不建议这样做。因为上面的代码涉及到了字符串的拼接， 会产生很多String对象，占用空间，影响程序性能。

可以使用 [{}] 进行参数的隔离

如果有参数变量，可以写成下面这样：

这样的格式写法，对于排查问题更有帮助。

不同级别的使用

ERROR

定义：影响到程序正常运行，当前请求正常运行的异常情况：

1. 打开配置文件失败
2. 对接第三方的异常（包括第三方返回错误码）
3. 所有影响功能使用的异常。包括sqlException和除了业务异常之外的所有异常（runtimeException，Ecxception）

如果抛出了异常，就不要记录error日志，有最终处理方式进行处理。

如下图：

WARN

定义：不应该出现但是不影响程序，当前请求正常运行的异常情况：

1. 有容错机制的时候出现的错误情况
2. 找不到配置文件，但是程序可以自动创建或者能够继续向下执行
3. 缓存池占用接近临界值的时候
4. 接口抛出业务异常的时候

INFO

定义:系统运行信息，外部接口

1. service中对于系统/业务状态的变更
2. 主要逻辑分步骤
3. 客户端请求参数
4. 调用第三方的调用参数和调用结果

这里同样也是要有所抉择的，普通简单service是没有意义的。不是针对每个业务都这样做，

这里对于复杂的业务逻辑，例如电商系统中的下订单逻辑，工业系统的停送电逻辑等等

DEBUG

定义：可以填写想知道的相关信息，最好有相关参数，生产环境需要关闭debug，如果需要开启的话，需要使用开关进行管理，不能一直开启

TRACE

定义：特别详细的系统运行信息。业务代码中，不要使用（除非有特殊用意，否则用debug代替）

trace的级别比debug还要低一些，并且会自动检查级别，如果高于trace就跳过。

而debug是先生产要打印的语句，然后再检查级别。如果高于debug就不输出

所以要debug进行判断，否则会生成多余的对象。