Java日志框架研究及常见配置

谁践踏了优雅 2022-05-08 10:24 242阅读 0赞

转载自：[https://blog.csdn.net/clannadyue/article/details/49123925][https_blog.csdn.net_clannadyue_article_details_49123925]

按照基本的定义，日志即是对程序运行过程中关键事件的记录；大体日志分为运行日志和开发日志，运行日志在业务层面记录一些关键事件，为后面的跟踪运行提供帮助，而开发日志大多数时候是调试日志，根据事件流的输出来调试程序；因为开发人员本身的关注领域，运行日志可能制作的比较少，难以达到跟踪业务流的作用，而即使是开发日志，因为开发的调试有各种技巧，即使是跟踪事件流，使用println也比日志配置简单多了，这是一个投资回报的问题，而人经常性的是短视的，调试可能在这些人眼里根本不需要认真对待，没有前期的事件记录规划，随着系统规模膨胀，执行流增多，执行事件保障，这时候没有一种合理的“开关”机制来选择查看感兴趣事件流，那结局是明晰的，日志不止提供了一种树形的开关结构，它还有灵活的输出控制，在Java常用日志框架Log4J还提供了JMX等接口，可以通过管理面板来监控和修改日志记录行为，这无疑是非常诱人的。

大体上Java体系中比较常用的日志框架如下

<table> 
 <tbody> 
 <tr> 
 <td> 日志框架 </td> 
 <td> 支持日志级别 </td> 
 </tr> 
 <tr> 
 <td> Log4J </td> 
 <td> FATAL ERROR WARN INFO DEBUG TRACE </td> 
 </tr> 
 <tr> 
 <td> Java Logging API </td> 
 <td> SEVERE WARNING INFO CONFIG FINE FINER FINEST </td> 
 </tr> 
 <tr> 
 <td> Apache Commons Logging </td> 
 <td> FATAL ERROR WARN INFO DEBUG TRACE </td> 
 </tr> 
 <tr> 
 <td> SLF4J </td> 
 <td> ERROR WARN INFO DEBUG TRACE </td> 
 </tr> 
 <tr> 
 <td> Logback </td> 
 <td> ERROR WARN INFO DEBUG TRACE </td> 
 </tr> 
 <tr> 
 <td> Jboss logging </td> 
 <td> FATAL ERROR WARN INFO DEBUG TRACE </td> 
 </tr> 
 </tbody> 
</table>

按照我比较有限的经验，我大多时候使用的是Log4J1.x版本，在配置一些开源框架时，可能需要到**Apache Commons Logging**和**SLF4J，**在配置Jboss系工具和框架的时候需要用到**Jboss logging**（例如Hibernate），其他日志框架如Java Logging，为Java自带的，功能上比较简单，用的也不是很多 ，而另一个Logback，这是一个号称Log4J继承者的新一代日志框架，因为我对“新一代”这个名词比较不感冒，我还没有怎么看，感兴趣的可以看看。

基本上，日志级别是很相似的，这不仅仅是Java生态范围内，整个编程行业应该都有共识，通过日志级别来标记事件的轻重缓急，我们可以通过这个条件进行过滤，显示我们感兴趣的内容，关于日志级别之间的相互关系，这个比较简单，这里就不再说了。

优秀的编程设计原则中有一条“依赖倒置”，要依赖抽象，不要依赖具体，具体的实践就是面向接口设计了，优秀的项目都会定义高层次抽象，通过封装隐藏多余的信息，这样在代码变动或者想不修改原有代码扩展的时候（开闭原则），能够相对容易的满足这些需求，而这些日志框架设计结构中则充分发挥了面向接口设计的优良传统，日志框架的核心接口是Logger类（接口），其他部分则是围绕此类（接口）展开，这里我们看两个定义例子，SLF4J的Logger定义如下

![Center][]

**Apache Commons Logging**的Log定义如下

![Center 1][]

因为其他的日志框架实在都太“重量级”了，方法太多，这里就不贴出定义了，日志框架定义了基本的接口，通过提供一个Facade，而后端由谁去实现就不那么重要了，这里面Apache Commons Logging、SLF4J、Jboss logging都容许其他后端实现为别的日志框架（大部分为Java Logging 、Log4J，差异化的部分在讲这些日志框架的时候再详细叙述），如何将Facade的请求转为后端可识别请求，知道一点设计模式的人应该马上想到适配器模式，这里，我们想给出几个日志框架如何实现这个接口适配的解决方法，我们一一道来。

Apache Commons Logging

![Center 2][]

这是标准的适配器模式，没有什么好讲的，Apache Commons Logging提供的实际工作类如下

![Center 3][]

这里面我们比较熟悉的是JDK自带的Java Logging和Log4J，其他几个因为不怎么常用就不说了，关于Apache Commons Logging如何选择具体的实现类，这个可以从LogFactory的实现类中查找到逻辑，逻辑代码如下：

![Center 4][]

![Center 5][]

因为代码比较长，这里只贴出关键部分逻辑，可以看得很清楚，用户通过配置文件指定后端实现，反之通过查找类路径来选择具体实现类。

SLF4J

SLF4J也存在上述类似的适配方式，这里我们给出SLF4J有些不同的bridge方式，其形式类似适配，如下

![Center 6][]

这个结构有些复杂，这里是SLF4J到Log4J的桥接，我们看到Log4jLoggerFactory提供了类似的适配功能，这种方式的好处，按照官方文档的说法是提供了编译时绑定，排除了运行时的探测方式，性能会好一些，看着这图有些抽象，这里给出一个具体的应用场景，如下

Spring日志配置

Spring项目使用了Apache Commons Logging日志框架，因为该日志框架比较老旧，我们一般使用Log4J作为其后端实现，通过上面的介绍，我们知道只要将Log4J放入ClassPath中就可以了，如果使用maven，在依赖中添加Log4J就可以了，这里如何使用SLF4J的桥接，结果有些复杂，首先需要去掉Apache Commons Logging依赖，然后添加Spring到SLF4J的Bridge，然后使用一个后端实现Log4J，因此在添加一个SLF4J到Log4J的Bridge，最后是Log4J实现，用maven管理的话，结果如下

<dependencies> 
    <dependency> 
        <groupId>org.springframework</groupId> 
        <artifactId>spring-core</artifactId> 
        <version>4.2.2.BUILD-SNAPSHOT</version> 
        <exclusions> 
            <exclusion>

<groupId>commons-logging</groupId> 
                <artifactId>commons-logging</artifactId> 
            </exclusion> 
        </exclusions> 
    </dependency> 
    <dependency>

**** 
        <groupId>org.slf4j</groupId> 
        <artifactId>jcl-over-slf4j</artifactId> 
        <version>1.5.8</version> 
    </dependency> 
<dependency>

**** 
        <groupId>org.slf4j</groupId> 
        <artifactId>slf4j-api</artifactId> 
        <version>1.5.8</version> 
    </dependency> 
    <dependency>

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

<groupId>log4j</groupId> 
        <artifactId>log4j</artifactId> 
        <version>1.2.14</version> 
    </dependency> 
</dependencies> 
这种方式比较复杂，因为在平时工作中没有用过SLF4J日志框架，所以这种方式看起来有些多此一举，但考虑到SLF4J作为事实上的Java Logging标准，如何更加有效的在不同前端Facade Logger接口到后端实现之间自由适配，SLF4J提供了一个很好的形式，如下

![Center 7][]

前端到后端的适配能够更加方便，这确实是一个非常有趣的想法。

Jboss logging

事实上这个日志框架貌似不是很出名，但是基本上Jboss系的产品、框架都会使用这个日志框架，因此，我们也需要好好的学习一下，该日志结构如下

![Center 8][]

这里的也是一种适配器方式，只是最终暴露的使用接口是特定的LoggerProvider，查找特定日志框架的LoggerProvider是由LoggerProviders提供的，代码如下

![Center 9][]

代码显示在LoggerProviders加载时就开始查找特定LoggerProvider，具体查找逻辑如下

![Center 10][]

上面看到的是通过配置文件查找

![Center 11][]

后半部分是根据ClassPath查找。

Jboss logging比较奇特的地方是其提供了一个JBossLogManagerLogger，这个Logger使用的内部Logger为JBoss容器托管日志管理器，这个可以注意一下

上面分析了日志框架前端Facade和后端实现如何适配，现在我们选取一个具体的框架来给出一些常见配置，希望能够对大家有用，我们选取的就是Log4J，因为其他框架我使用的频率比较低，二来因为日志框架的概念都类似，熟悉了一个其他的应该也可以快速掌握，下面让我们展开对Log4J的论述。

Log4J来自于Apache社区，是目前应用最广的一个日志框架，官方提供了两个大的版本，为Log4J 1.x和Log4J 2.x，这两个主版本连官网链接都不一样，看来Log4J 2.x应该针对前一版本问题而重新设计，以至于导致和前一版本的不兼容，但因为Log4J 1.x普及的根深蒂固，很多日志框架没有及时跟上对Log4J 2.x后端的支持，Log4J 2.x彻底替换掉Log4J 1.x还有很长的一段路要走。

这里我们给出的是Log4J 1.x的版本介绍，关于Log4J 2.x，我们有机会再进行探索；在Log4J的体系里，有三个最重要的概念：Logger、Appender、Layout，Logger即为日志写入入口，Appender定义了将日志时间输出的策略，Layout给出输出的格式，三者的关系如下

![Center 12][]

因为Log4J中有Category的概念，这里我把它看成一个Logger，三者的关系这样看起来比较明显，Logger接收日志记录，Appender接收Logger发来的日志事件，然后根据Layout定义格式进行输出，这里没有什么好讲的，我们开始讲如何配置。

Log4J 1.x有两种配置方式，一种是Java properties文件，一种是XML，第一种用的比较多一些，这个和Log4J 2.x正好相反，配置文件配置主要配置上面三个对象，配置Logger，然后配置使用哪种具体Appender，然后定义格式，看一个例子，如下：

log4j.rootLogger=DEBUG, A1

log4j.appender.A1=org.apache.log4j.ConsoleAppender

log4j.appender.A1.layout=org.apache.log4j.PatternLayout

log4j.appender.A1.layout.ConversionPattern=%-4r %-5p \[%t\] %37c %3x - %m%n

如上，一定要定义的Logger是root Logger，这里构成了一个类似树形结构，顶部节点定义默认行为，子节点可以对行为进行修改定制，这里定义rootLogger使用DEBUG级别，使用A1这个Appender，注意这里的写法：第一个为日志级别，后面可以跟很多个Appender；线面定义了这个具体的Appender A1，我们看到其使用的是ConsoleAppender，后面我们给这个Appender指定Layout，这里的Layout为PatternLayout，这个比较常用，最后一行定义了日志格式，这种格式写法类似于printf那种格式化字符串，里面的占位符构成为"%\[格式修饰符\]日志含义符号"（中括号里的为可选），格式修饰符比较简单，“-”代表靠左对其，不加就是靠右对其，后面的数字代表了该日志内容部分的最少显示长度，如果有“.”,"."之后为该日志内容最长显示长度，超过长度会进行裁短；后面的日志含义符号如下表

<table> 
 <tbody> 
 <tr> 
 <td> 符号 </td> 
 <td> 意义 </td> 
 </tr> 
 <tr> 
 <td> c（小写） </td> 
 <td> 输出日志的类别 </td> 
 </tr> 
 <tr> 
 <td> C（大写） </td> 
 <td> 输出触发日志请求的类的全称 </td> 
 </tr> 
 <tr> 
 <td> d </td> 
 <td> 输出日志事件的日期时间 </td> 
 </tr> 
 <tr> 
 <td> F </td> 
 <td> 输出日志请求类文件名 </td> 
 </tr> 
 <tr> 
 <td> l </td> 
 <td> 输出请求日志调用位置信息 </td> 
 </tr> 
 <tr> 
 <td> L </td> 
 <td> 输出请求日志代码行号 </td> 
 </tr> 
 <tr> 
 <td> m </td> 
 <td> 输出应用提供的日志消息 </td> 
 </tr> 
 <tr> 
 <td> M </td> 
 <td> 输出请求日志方法名 </td> 
 </tr> 
 <tr> 
 <td> n </td> 
 <td> 输出平台特定的行分隔符 </td> 
 </tr> 
 <tr> 
 <td> p </td> 
 <td> 输出日志级别 </td> 
 </tr> 
 <tr> 
 <td> r </td> 
 <td> 输出从程序启动到现在的毫秒数 </td> 
 </tr> 
 <tr> 
 <td> t </td> 
 <td> 输出生成这个日志事件线程的名字 </td> 
 </tr> 
 </tbody> 
</table>

这里在给出一个例子

log4j.rootLogger=DEBUG, A1

log4j.appender.A1=org.apache.log4j.ConsoleAppender

log4j.appender.A1.layout=org.apache.log4j.PatternLayout

log4j.appender.A1.layout.ConversionPattern=%p \[%t\] %c\{2\} (%M:%L) - %m%n

log4j.logger.org.apache.log4j.examples=INFO, A2

log4j.appender.A2=org.apache.log4j.FileAppender

log4j.appender.A2.File=$\{user.home\}/test

\#如果test文件存在就先清空它

log4j.appender.A2.Append=false

log4j.appender.A2.layout=org.apache.log4j.PatternLayout

log4j.appender.A2.layout.ConversionPattern=%5r %-5p \[%t\] %c\{2\} - %m%n

上面的例子稍微复杂一些，这里设定了一个rootLogger，并制定了其日志级别和Appender，后面定义了一个名为org.apache.log4j.examples 的Logger，这个Logger又定义了日志级别和Appender，通过这里的例子可以看出Log4J这种树形的关系具有足够的灵活性。

关于XML的配置，这里给出一个实例，大家可以根据上面对properties的理解来配置XML，如下

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE log4j:configuration PUBLIC "-//APACHE//DTD LOG4J 1.2//EN" "log4j.dtd"> 
<log4j:configuration xmlns:log4j='[http://jakarta.apache.org/log4j/][http_jakarta.apache.org_log4j]'> 
    <appender name="STDOUT" class="org.apache.log4j.ConsoleAppender"> 
        <layout class="org.apache.log4j.PatternLayout"> 
            <param name="ConversionPattern" value="%d %-5p \[%t\] %C\{2\} (%F:%L) - %m%n"/> 
        </layout> 
    </appender> 
    <category name="org.apache.log4j.xml"> 
        <priority value="info" /> 
    </category> 
    <Root> 
        <priority value ="debug" /> 
        <appender-ref ref="STDOUT" /> 
    </Root> 
</log4j:configuration>

这里的category如前面分析结构时所说，可以认为其就是一个Logger，这个结构也比较一目了然，没有什么要讲的，大家可以根据自己的实际需要来调整结构。

这里还有个问题是配置文件命名的问题，默认情况下，如果配置文件命名为log4j.xml或log4j.properties时Log4J会自动加载，如果因为某种原因不能这样命名，那么久需要编码来实现配置的加载了，代码片段如下

String resource =

"/app/resources/example.properties";

URL configFileResource =

InitUsingPropertiesFile.class.getResource(resource);

PropertyConfigurator.configure(configFileResource);

日志框架就写这些吧，希望能对大家有所帮助，对单一常用日志框架的详细解析，有机会在写吧

[https_blog.csdn.net_clannadyue_article_details_49123925]: https://blog.csdn.net/clannadyue/article/details/49123925
[Center]: /images/20220508/e0d5a192438e483c9a8b48332b0fe796.png
[Center 1]: /images/20220508/e721a56e66d14aa3b8e79c22b978ea93.png
[Center 2]: /images/20220508/a0146f547145427688977496f73da169.png
[Center 3]: /images/20220508/eb24719012ac4e14a7173f8e8c9aa0fa.png
[Center 4]: /images/20220508/367881f289ce4c6781b9d3a3a5d2d00f.png
[Center 5]: /images/20220508/2c92433cadce4d0fae312943b2c40eef.png
[Center 6]: /images/20220508/c3de9b5158b248608419d50dbe162f21.png
[Center 7]: /images/20220508/c784d1bb1b7e4be394ba66a98a9750a6.png
[Center 8]: /images/20220508/36a0d608af0f49c4a04a6c887f62b449.png
[Center 9]: /images/20220508/e69c267bda044538b5fca29f983c2a1d.png
[Center 10]: /images/20220508/10126595de56438991e995c0915d470f.png
[Center 11]: /images/20220508/56030377ede44cdb9b406ad1965db674.png
[Center 12]: /images/20220508/c5424262b80e48ccaa02408f1617b05f.png
[http_jakarta.apache.org_log4j]: http://jakarta.apache.org/log4j/