本篇文章，主要介绍应用如何正确使用日志系统，帮助用户从依赖、输出、清理、问题排查、报警等各方面全面掌握。
日志相关的包的种类及使用
▐ 日志系统与日志框架
每个应用为了方便排查问题都要输出日志，大家经常使用：log4j、logback等。我们先搞明白日志系统的整套体系是如何运作的。
- 日志系统
直接负责打印输出日志，提供完整的日志输出能力：
- JUL
- java.util.logging.*，java自带的日志系统简称JUL。目前除了Java自身代码很少被生态系统类库使用。
- Log4j
- https://logging.apache.org/，目前已经发展到2.x版本（2.x版本有超越logback的趋势），早期的1.x版本非常成功。开创日志系统模型（Logger\Appender\Level等概念）并被各种日志框架采用，且一直沿用至今
- log4j可直接使用，也可配合日志框架一起使用
- Logback
- http://logback.qos.ch/，Log4j作者的另一个作品，（比Log4j1.x新，Log4j2.x旧）吸取多年经验教训重新设计的一套日志系统，使用更方便、功能更强、性能更好。
- logback不能单独使用，需配置日志框架SLF4J一起使用
- 日志框架
为了克服各种日志系统标准混乱，诞生了日志框架，日志框架不提供日志输出的功能，它定义标准，提供标准接口API，日志框架+日志系统=输出日志。写代码过程中使用日志框架的好处：编码的时候调用日志框架API，部署的时候可根据不同的环境在多种日志系统中随意切换。
- JCL
- https://commons.apache.org/proper/commons-logging/，前几年最流行的日志框架，由Apache社区维护，大量的老牌知名框架版本都在使用，比如Spring（甚至新版本依然在使用）。
- SLF4J
- https://www.slf4j.org/，Log4j作者推出，这几年最流行的日志框架，特别是配合Logback使用。
- 当然也可以配合log4j使用
目前在Java生态趋势主要是使用：SLF4J+Logback组合。
▐ 如何正确组合使用日志系统和日志框架
上一节我们介绍了日志框架和日志系统，因为存在多套，所以：如何在系统中正确使用是我们的重点。
- 日志系统之间互斥
- 日志框架：JCL和JCL-over-SLF4J桥接包直接互斥
- 日志系统：logback和slf4j-log4j12互斥，不能共存
我们大概可枚举出如下几种组合：
类型 |
说明 |
slf4j+logback |
目前最主流的玩法，除了依赖slf4j、logback，还需要考虑把二方库和三方库内部使用的jcl和log4j桥接到slf4j上来，并避免依赖反桥接的包 |
slf4j+log4j |
不推荐。需要把slf4j桥接到log4j，并把jul桥接到slf4j |
jcl+log4j |
不推荐。这需要你直接使用jcl接口来编码，并把把slf4j桥接到log4j |
log4j |
不推荐。直接依赖日志系统 |
- slf4j+logback组合
下面列出一个正确的slf4j+logback依赖，这个环节很重要，很多应用因为依赖搞不清楚经常出现日志丢失问题：
<properties> <slf4j.version>${xxxx}</slf4j.version> <logback.version>${yyyyy}</logback.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>com.alibaba.external</groupId> <artifactId>jakarta.commons.logging</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>com.alibaba.external</groupId> <artifactId>org.slf4j.slf4j-log4j12</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-nop</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>com.alibaba.external</groupId> <artifactId>org.slf4j.slf4j-simple</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>999-not-exist</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-ext</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jul-to-slf4j</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>${logback.version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>${logback.version}</version> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-ext</artifactId> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jul-to-slf4j</artifactId> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> </dependency> </dependencies>
- 先将依赖全部写在<dependencyManagement>节点中，这样可影响间接依赖，如果只当初的使用dependencies节点，只会应用直接依赖
- 使用999-not-exist这样的版本：欺骗maven，直接依赖一个空包占位，这样Maven就不会再去依赖相同坐标的真实依赖，间接起到排包的作用
▐ logback配置
- 文件名和位置
应用类型 |
文件名 |
文件配置（启动模块） |
说明 |
spring-boot |
logback-spring.xml |
src/main/resources/ |
支持从spring-boot配置文件中直接读取property |
普通java应用 |
logback.xml |
src/main/resources/ |
|
WAR应用 |
logback.xml |
src/main/webapp/WEB-INF/ |
需要依赖slf4j-ext，然后在web.xml里使用监听器挂载这个文件 |
单元测试和集成测试 |
logback-test.xml |
src/test/resources/ |
- 配置样例
<?xml version="1.0" encoding="UTF-8"?> <configuration> <property name="APP_NAME" value="demo1" /> <property name="LOG_PATH" value="${user.home}/${APP_NAME}/logs" /> <property name="LOG_FILE" value="${LOG_PATH}/application.log" /> <property name="LOG.PATTERN" value="%d %-5level %X{EAGLEEYE_TRACE_ID} %logger{5}[%L] - %msg%n"/> <property name="LOG.CHARSET" value="UTF-8"/> <appender name="APPLICATION" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${LOG_FILE}</file> <encoder> <pattern>${LOG.PATTERN}</pattern> <charset>${LOG.CHARSET}</charset> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <maxHistory>7</maxHistory> <maxFileSize>50MB</maxFileSize> <totalSizeCap>20GB</totalSizeCap> </rollingPolicy> </appender> <logger name="org.springframework" additivity="false"> <level value="error"/> <appender-ref ref="APPLICATION"/> </logger> <logger name="com.ibatis" additivity="false"> <level value="error"/> <appender-ref ref="APPLICATION"/> </logger> <logger name="org.mybatis" additivity="false"> <level value="error"/> <appender-ref ref="APPLICATION"/> </logger> <logger name="java.sql" additivity="false"> <level value="error"/> <appender-ref ref="APPLICATION"/> </logger> <logger name="sqlMonitor" additivity="false"> <level value="error"/> <appender-ref ref="APPLICATION"/> </logger> <logger name="com.taobao" additivity="false"> <level value="error"/> <appender-ref ref="APPLICATION"/> </logger> <logger name="com.alibaba" additivity="false"> <level value="error"/> <appender-ref ref="APPLICATION"/> </logger> <logger name="com.alibaba.example.demo" additivity="false"> <level value="info"/> <appender-ref ref="APPLICATION"/> </logger> <root level="error"> <appender-ref ref="APPLICATION" /> </root> </configuration>
- 使用SizeAndTimeBasedRollingPolicy使日志可以根据大小和日期进行滚动
- 日志编码请使用UTF-8
- 请正确使用日志级别，不要统统输出error
- 日志级别根据不同环境可配
- 如果是Pandora-boot或spring-boot可以直接在配置里使用property读取application.properties，application.properties在不同环境下使用-Dspring.profiles.active进行切换
- 普通应用和WAR应用：请使用autoconfig-maven-plugin插件
一些实用的日志技巧
▐ 动态修改日志级别
场景：应用在运行中，默认日志配置的打印级别是error，但是我现在想针对某个包或者某个类输出下info日志。
使用Arthas：https://arthas.aliyun.com/doc/logger.html，该工具提供了动态修改日志的能力。
▐ 追加业务信息到日志中，并格式化输出：追加MDC信息，方便排查问题
这是日志系统的一个扩容能力，可以把一些额外的信息输出到日志里，只需要在MDC上下文中写入kv，https://logback.qos.ch/manual/mdc.html
例如：
public static void main(String[] args) { //代码里使用MDC.put写入key为traceId的值 //在logback.xml里就可以使用%X{traceId}进行输出 MDC.put("traceId", UUID.randomUUID().toString().replace("-", "")); }
▐ 配置定时日志磁盘占用清理
一定要配置合理的日志清理策略，避免磁盘被打爆，可借助日志框架自身能力，或借助可用的日志清理系统（如果有）
在logback.xml配置中，可通过配置带有清理作用的rollingPolicy来完成日志定时清理和滚动，例如：SizeAndTimeBasedRollingPolicy
这段配置的含义是：最多保留7天，单个文件最大50MB，该日志（包括滚动的）最大只能保存20GB。
▐ 不要封装一个日志Util，而应该直接使用日志框架进行输出
反例：LogUtil.log("通过封装的日志工具打印日志");
正例：log.info("直接使用日志框架的api进行日志输出");
理由：在日志输出的时候，日志系统会打印日志产生的原始位置：比如哪个包的哪个类，以及第几行（如果配置了[%L]），如果你使用LogUtil等自己封装的工具，所有的日志输出打印的位置都是LogUtil的，这样不便于做日志问题定位
系统日志打不出来或者丢日志排查思路
目前没有现成的工具帮你一键做好这个事情，下面给出一个排查思路
- 先明确该系统到底使用的是什么日志框架+日志系统组合，这个很重要，必须搞清是何种组合才可有针对性的处理后续步骤
- 如果是slf4j+logback组合，则可根据第一章列出的maven依赖进行排包处理，优先保证依赖的包没有错误，90%的情况下都是包依赖混乱导致的日志丢失
- 排查自己的logback配置文件是否放在正确的路径下、文件名是否正确，配置文件位置不对也会导致日志输出的不对甚至丢失
- 检查logback配置文件内部每个logger及其level配置是否正确，避免自己期望打印info，却配置了error
总结
日志系统的正确使用，对于应用的日常维护和问题排查尤为重要，所谓：工欲善其事，必先利其器。本篇文章重点讲解了日志系统的结构和包如何正确依赖，这是很多同学最容易犯的错误，需要格外注意并认真阅读，只有正确理解其中的含义才可以更好的使用日志系统，在日常使用中大家要不断总结经验。
最后希望文章提供的内容能够在日常开发和维护中为大家提供到切实的帮助。
团队介绍
物流技术团队是服务淘天物流部及零售行业的产技团队，一直深耕在物流及供应链的数字化协同与运营领域：为零售业务提供灵活多样的经营模式管理方案及可以快速适配市场变化的经营策略数宇化管理工具；为商家提供高效低成本的物流及供应链解决方案，加快资金效率，提升协同效率；为消费者提供即时便捷的购物体验。
