Log4j日志框架使用

Log4j是Apache下的一款开源的日志框架，能够满足我们在项目中对于日志记录的需求。一般来讲，在项目中，我们会结合slf4j和log4j一起使用。Log4j提供了简单的API调用，强大的日志格式定义以及灵活的扩展性。我们可以自己定义Appender来满足我们对于日志输出的需求。

什么是日志框架

我们在系统中对于记录日志的需求并不单纯。首先，我们希望日志要能持久化到磁盘，最基本的就是要能够保存到文件中；其次，我们希望在开发和生产环境中记录的日志并不相同，明显开发环境的日志记录会更多方便调试，但放到生产环境下大量的日志很容易会撑爆服务器，因此在生产环境我们希望只记录重要信息。

基于不单纯的目的，System.out.println是直接不能满足我们的要求，因此抛弃它，选择功能更强的日志框架。而log4j是apache下一款著名的开源日志框架，log4j满足上面的一切需求。

记录日志的框架并不仅仅只有log4j，比较有名的还有logback等，现在比较火的SpringBoot默认集成的日志就是logback。不管哪种日志框架，一般都能够实现日志的持久化功能。

集成slf4j-log4j到系统

slf4j-log4j的使用也是非常简单的，几个jar包，一个配置文件（log4j.properties）就可以了。把jar包和配置文件都放到classpath下就可以了。那么配置文件都写些什么，一会再说，这是一个重点。

如果使用Maven来管理就更方便了，只需要导入如下依赖即可

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.25</version>
</dependency>

log4j的日志级别

早就听说有日志级别这么回事，日志级别到底是个什么鬼？刚才提到了两个需求，一个是保存日志到不同的地方，另一个是开发和生产环境打印不同的日志，那么如何在不同的环境打印不同的日志，就是由日志级别来实现的。

日志一般分5个等级，从低到高分别是 DEBUG INFO WARN ERROR FATAL。对应中文的意思就是调试信息一般信息警告信息错误信息严重错误信息。在记录日志的时候，就可以根据不同的日志级别来进行记录。比如，你要监控一下用户提交上来的注册信息，我们认为这是在开发环境才需要的，因此可以使用DEBUG级别记录。再比如一个支付场景，系统抛出了一个未知的异常，这肯定是一个非常严重的问题了，那么可以用FATAL或者ERROR来记录。

了解清楚等级划分之后，再来控制生成环境和开发环境输出的信息不同就很简单了，我可以配置一个最低的日志输出级别，在开发环境我设置为DEBUG，也就是所有的日志信息都能输出。在生产环境我可以设置为WARN，也就是只有WARN及以上级别的日志才会被输出，这样是不是就可以在不同的环境控制不同的日志输出了。

对于开发者，学习如何记录各等级的日志非常简单，日志框架一般都提供了非常人性化的API。比如记录debug信息就是 logger.debug(String msg) 记录 info信息就是 logger.info(String msg) 等等，logger是实例化的日志对象。复杂的在于什么场景下使用哪一个级别的日志信息，关于这个问题，在阿里的《java开发手册》的日志规约部分写的非常好，有兴趣的朋友可以参考一下。文档地址在《Java开发手册》

log4j的appender

Appender是log4j的另一大优势，解决的就是日志输出目的地的问题。我们可以自己实现Appender来决定让日志输出到哪里。当然框架默认给我们已经提供了一些常用的Appender，比如输出到控制台的org.apache.log4j.ConsoleAppender，输出到文件的org.apache.log4j.DailyRollingFileAppender等。系统已经默认给我们提供了大量的Appender，基本上可以满足我们的日常需求，当然如果你的需求比较特殊，可以自己实现Appender，也是非常简单的。只需要定义一个类，实现Appender接口就可以了。Appender接口中定义了一系列记录日志的方法，按照自己的规则实现这些方法即可。系统提供的Appender如下

log4j的配置

了解了log4j的两大核心，一个是日志级别，一个是Appender 之后，我们开始看看配置文件到底是什么样子的，下面一个截图，介绍了关于配置的大部分常用内容

注意，这里有一个日志的格式，也就是 ConversionPattern，那么这个值到底该如何配置呢？

%p：输出日志信息的优先级，即DEBUG，INFO，WARN，ERROR，FATAL。
%d：输出日志时间点的日期或时间，默认格式为ISO8601，也可以在其后指定格式，如：%d{yyyy/MM/dd HH:mm:ss,SSS}。
%r：输出自应用程序启动到输出该log信息耗费的毫秒数。
%t：输出产生该日志事件的线程名。
%l：输出日志事件的发生位置，相当于%c.%M(%F:%L)的组合，包括类全名、方法、文件名以及在代码中的行数。例如：test.TestLog4j.main(TestLog4j.java:10)。
%c：输出日志信息所属的类目，通常就是所在类的全名。
%M：输出产生日志信息的方法名。
%F：输出日志消息产生时所在的文件名称。
%L:：输出代码中的行号。
%m:：输出代码中指定的具体日志信息。
%n：输出一个回车换行符，Windows平台为"/r/n"，Unix平台为"/n"。
%x：输出和当前线程相关联的NDC(嵌套诊断环境)，尤其用到像java servlets这样的多客户多线程的应用中。
%%：输出一个"%"字符。
另外，还可以在%与格式字符之间加上修饰符来控制其最小长度、最大长度、和文本的对齐方式。如：
%20c：指定输出category的名称，最小的长度是20，如果category的名称长度小于20的话，默认的情况下右对齐。
%-20c："-"号表示左对齐。
%.30c：指定输出category的名称，最大的长度是30，如果category的名称长度大于30的话，就会将左边多出的字符截掉，但小于30的话也不会补空格。

到这里，log4j的配置就完成了。

一个简单的log4j配置文件的案例如下

### 设置###
log4j.rootLogger=DEBUG,stdout,E
log4j.logger.io.netty=WARN
log4j.logger.com.mchange=WARN
### 输出信息到控制抬 ###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%p %d{HH:mm:ss} [%c:%L] %m%n
### 输出DEBUG 级别以上的日志到=E://logs/error.log ###
log4j.appender.D=org.apache.log4j.DailyRollingFileAppender
log4j.appender.D.File=E://logs/log.log
log4j.appender.D.Append=true
log4j.appender.D.Threshold=DEBUG
log4j.appender.D.layout=org.apache.log4j.PatternLayout
log4j.appender.D.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss}  [ %t:%r ] - [ %p ]  %m%n
### 输出ERROR 级别以上的日志到=E://logs/error.log ###
log4j.appender.E=org.apache.log4j.DailyRollingFileAppender
log4j.appender.E.File=E://logs/error.log
log4j.appender.E.Append=true
log4j.appender.E.Threshold=ERROR
log4j.appender.E.layout=org.apache.log4j.PatternLayout
log4j.appender.E.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss}  [ %t:%r ] - [ %p ]  %m%n

slf4j日志框架

Slf4j是一款日志记录框架，我们的项目中可能会用到很多的日志，比如commons-logging,又或者是log4j等等，那么不同的日志工具提供了不同的日志接口，我们的项目如果想换一个日志框架，可能需要改动许多的代码，这样slf4j就给我们提供了一种便捷的方式。它提供了一种对日志工具更高一层的抽象，只要导入slf4j的包和slf4j和采用日志工具整合的包，我们就可以使用slf4j来记录日志了，不用去考虑具体的日志工具的接口。那么以后如果要改变日志工具，我们就可以直接将要使用日志工具加到我们的项目中，而不需要改动代码。

日志跟踪（MDC）

高并发环境下，日志输出很容易出现找不到的情况，在传统阻塞模型下，针对每次请求都是一个线程，因此在输出格式的时候，输出线程名就可以实现了，那么跟日志的时候，就可以根据线程的名字进行跟踪。

当然这种跟踪方式有很多的弊端，首先线程是在线程池中的，来来回回也就那么几个线程，所有如果并发量很大，这种方式并不合适。另外对于多机环境，使用线程名的方式也并不靠谱。

为了解决线程名方式带来的问题，可以在当前线程中放置一个变量的形式，而这个变量的值可以是订单号，也可以随机。在日志输出的时候，将这个值输出出来，就可以保证每个线程的每次请求值是相同的。根据这个值就可以跟踪日志了。

这个值的存储可以使用ThreadLocal来存储，但实现还是比较麻烦，而日志又都有这个需求，因此日志框架就给我们提供了这个便捷的操作。MDC！

可以直接通过MDC.set(String key, String value)来设置。比如设置一个uid,值为UUID随机生成。就可以写成MDC.set("uid",UUID.randomUUID().toString());

在日志的配置文件中，加上 %uid 就可以输出这个值了。

转载自：https://blog.csdn.net/king_kgh/article/details/80430002#comments_13990017