本篇文章,主要介绍应用如何正确使用日志系统,帮助用户从依赖、输出、清理、问题排查、报警等各方面全面掌握。
日志相关的包的种类及使用
每个应用为了方便排查问题都要输出日志,大家经常使用: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依赖,这个环节很重要,很多应用因为依赖搞不清楚经常出现日志丢失问题:
${xxxx}
${yyyyy}
commons-logging
commons-logging
999-not-exist
com.alibaba.external
jakarta.commons.logging
999-not-exist
org.slf4j
slf4j-log4j12
999-not-exist
com.alibaba.external
org.slf4j.slf4j-log4j12
999-not-exist
org.slf4j
slf4j-nop
999-not-exist
org.slf4j
slf4j-simple
999-not-exist
com.alibaba.external
org.slf4j.slf4j-simple
999-not-exist
log4j
log4j
999-not-exist
org.slf4j
slf4j-api
${slf4j.version}
org.slf4j
slf4j-ext
${slf4j.version}
org.slf4j
jcl-over-slf4j
${slf4j.version}
org.slf4j
jul-to-slf4j
${slf4j.version}
org.slf4j
log4j-over-slf4j
${slf4j.version}
ch.qos.logback
logback-core
${logback.version}
ch.qos.logback
logback-classic
${logback.version}
org.slf4j
slf4j-api
org.slf4j
slf4j-ext
org.slf4j
jcl-over-slf4j
org.slf4j
jul-to-slf4j
org.slf4j
log4j-over-slf4j
ch.qos.logback
logback-core
ch.qos.logback
logback-classic
先将依赖全部写在
使用999-not-exist这样的版本:欺骗maven,直接依赖一个空包占位,这样Maven就不会再去依赖相同坐标的真实依赖,间接起到排包的作用
应用类型 |
文件名 |
文件配置(启动模块) |
说明 |
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/ |
${LOG_FILE}
${LOG.PATTERN}
${LOG.CHARSET}
${LOG_FILE}.%d{yyyy-MM-dd}.%i.log
7
50MB
20GB
使用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上下文中写入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。
反例:LogUtil.log("通过封装的日志工具打印日志");
正例:log.info("直接使用日志框架的api进行日志输出");
理由:在日志输出的时候,日志系统会打印日志产生的原始位置:比如哪个包的哪个类,以及第几行(如果配置了[%L]),如果你使用LogUtil等自己封装的工具,所有的日志输出打印的位置都是LogUtil的,这样不便于做日志问题定位
系统日志打不出来或者丢日志排查思路
目前没有现成的工具帮你一键做好这个事情,下面给出一个排查思路
先明确该系统到底使用的是什么日志框架+日志系统组合,这个很重要,必须搞清是何种组合才可有针对性的处理后续步骤
如果是slf4j+logback组合,则可根据第一章列出的maven依赖进行排包处理,优先保证依赖的包没有错误,90%的情况下都是包依赖混乱导致的日志丢失
排查自己的logback配置文件是否放在正确的路径下、文件名是否正确,配置文件位置不对也会导致日志输出的不对甚至丢失
检查logback配置文件内部每个logger及其level配置是否正确,避免自己期望打印info,却配置了error
总结
日志系统的正确使用,对于应用的日常维护和问题排查尤为重要,所谓:工欲善其事,必先利其器。本篇文章重点讲解了日志系统的结构和包如何正确依赖,这是很多同学最容易犯的错误,需要格外注意并认真阅读,只有正确理解其中的含义才可以更好的使用日志系统,在日常使用中大家要不断总结经验。
最后希望文章提供的内容能够在日常开发和维护中为大家提供到切实的帮助。
团队介绍
物流技术团队是服务淘天物流部及零售行业的产技团队,一直深耕在物流及供应链的数字化协同与运营领域:为零售业务提供灵活多样的经营模式管理方案及可以快速适配市场变化的经营策略数宇化管理工具;为商家提供高效低成本的物流及供应链解决方案,加快资金效率,提升协同效率;为消费者提供即时便捷的购物体验。
¤ 拓展阅读 ¤
3DXR技术 | 终端技术 | 音视频技术
服务端技术 | 技术质量 | 数据算法