日志那些事儿——由一次bug引发的思考-client jar应该如何输出日志

前言

前面几篇“日志那些事儿”讲解了日志的重要性和相关使用。以slf4j+logback的使用为例,我们的步骤为:

  • 在工程中引入slf4j、logback相关Jar包
  • 编写配置文件logback.groovy/logback.xml等
  • 使用LoggerFactory.getLogger()得到logger使用。 从上面可以看出使用过程中非常重要的一个部分为编写配置文件logback.xml,配置文件中通常是配置我们所需要的appender和相关的logger,例如说配置console输出或者配置文件输出等。

一次需求和一次bug

一次需求

前段时间做过一次需求,要求的是尽量无侵入的输出某些请求参数到日志中,Web框架是Webx,在web层采用了valve实现了类似切片功能,在service层直接使用了aop。当然这些都不算关键,关键在于要尽量少的侵入应用,并且要在多个系统中使用。由于在不同应用中可能使用了不同类型的日志框架,所以将关键的aop逻辑、日志输出逻辑封装在client jar中,供应用系统使用。

一次bug

起因

前两天需要对系统升级某项功能,需要引入一个新的jar,升级完成在日常测试环境中部署够,服务功能正常,但是却发现一个非常严重的bug——所有的日志全部不输出了。经排查之后发现是引入的新client jar中使用了slf4j+log4j2,而原应用中使用的是slf4j+logback。前者中引入log4j2-slf4j-impl,后者中的logback-classic中都用org.slf4j.impl.StaticLoggerBinder.class,所以会发生multiple_bindings的错误,按照slf4j的官方文档的说明:

NOTE The warning emitted by SLF4J is just that, a warning. Even when multiple bindings are present, SLF4J will pick one logging framework/implementation and bind with it. The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be considered random. As of version 1.6.6, SLF4J will name the framework/implementation class it is actually bound to.

由于两个StaticLoggerBinder.class属于同名同包,按照hotspot的Jvm规范,会加载classpath下靠前的那个jar中的StaticLoggerBinder。

If the 2 classes have the same package name, i.e. com.mycompany.Client, then you end up in a situation where it is somewhat arbitrary which version of Client is loaded. It comes down to which is on the classpath first. This is a JAR hell situation.

所以,日志停止输出的原因很肯定是因为slf4j binding到了log4j-slf4j-impl中的StaticLoggerBinder,而没有使用logback进行输出。

解决

分析了原因,解决起来了就很简单了,暴力exclude了引入的client jar包中的log4j2相关依赖。重新部署验证后发现日志可以输出,问题解决

对于slf4j的思考

  • 这样做虽然解决了问题,但是并不完美。因为client jar包中引入了log4j2,并且配置了log4j2.xml的配置文件,本意肯定是想使用log4j2输出相关日志到自己指定文件,但是由于我暴力干掉了log4j2,client想输出日志到指定文件是不可能的了,client会将其日志输出到应用主日志中。
  • 当系统中出现两个及以上StaticLoggerBinder.class的时候,肯定不算是“最佳实践”。日志系统虽多,择其善者而从之。

对于client jar设计的思考

一次需求,一次bug,其实都与日志系统相关。这次bug的根本原因也算是因为client jar没有考虑到使用者的感受,把log4j2强加给使用者。client jar可能会有一些记录日志的需求,例如记录一些信息用于调试。那么当client jar有日志输出需求,如何更好地进行设计呢?

我觉得得从以下几个方面考虑:

  • 缩小jar包依赖范围,如果是基于maven,可以把client工程中依赖的日志相关jar scope设置为provided.
  • “感知”应用系统所使用的日志框架,匹配相应的日志框架
  • 不使用配置文件,改用编码配置logger

对于第二点,client jar必须要“感知”应用系统所使用的日志框架,例如究竟是使用了log4j还是log4j2,还是slf4j+logback,亦或者slf4j+log4j等,这样才可以知道client jar中可以使用哪些日志api。对于第三点,由于我们一般都通过xml等配置文件配置日志logger,但这种方式很不灵活。要适配多少种日志系统,就需要在client jar的classpath下放置多少种日志配置文件,而且没法在运行时指定appender,设置layout等等。

总结

如果在client jar中有日志输出的需求,一定要好好设计,千万不能坑了使用者。下篇文章将围绕如何设计包含日志输出的client jar。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏琯琯博客

awesome-sysadmin-cn资源

系统管理员 资源列表,内容包括:备份/克隆软件、云计算/云存储、协作软件、配置管理、日志管理、监控、项目管理 备份 备份软件 Amanda:客户端-服务器模型备...

716120
来自专栏架构师小秘圈

微服务架构实施原理

31130
来自专栏高性能服务器开发

(八)高性能服务器架构设计总结1——以flamigo服务器代码为例

这篇文章算是对这个系列的一个系统性地总结。我们将介绍服务器的开发,并从多个方面探究如何开发一款高性能高并发的服务器程序。

18020
来自专栏EAWorld

微服务之服务调用与安全控制

近年来,大多数企业IT软件均在向微服务架构转型,由于微服务架构采用了更细粒度的分布式拆分,对于服务调用安全方面的问题更复杂,更需要重视,需要整体的系统化解决方案...

19730
来自专栏IT大咖说

送给前端的你:可视化快速生成模拟数据服务——Easy Mock

? 内容来源:2017年11月18日,大搜车前端工程师高攀在“2017中国开源年会”进行《Easy Mock 接口数据模拟服务》演讲分享。IT 大咖说(微信i...

50760
来自专栏数据和云

实践真知:解决 Jdbc 连接 Oracle 12c 时快时慢的问题

李真旭@killdb Oracle ACE,云和恩墨技术专家 个人博客:www.killdb.com 编辑手记:认识 JDBC 连接在不同版本间的差异,准确找出...

43540
来自专栏ThoughtWorks

登录工程:传统 Web 应用中的身份验证技术|洞见

标题中的 “传统Web应用” 这一说法并没有什么官方定义,只是为了与“现代化Web应用”做比较而自拟的一个概念。 所谓“现代化Web应用”指的是那些基于分布式架...

41450
来自专栏Linyb极客之路

微服务架构:基于微服务和Docker容器技术的PaaS云平台架构设计(微服务架构实施原理)

基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设...

53110
来自专栏腾讯Bugly的专栏

快速定位crash的炫酷方式

本人所在项目组主要负责一款Android平台产品的开发,因为用户量比较大,正式版本发布后,每天Crash次数的上报量都在几十万量级,即便是内测版,每天Crash...

387120
来自专栏用户2442861的专栏

Java NIO浅析

作者:美团点评技术团队 链接:https://zhuanlan.zhihu.com/p/23488863 来源:知乎 著作权归作者所有。商业转载请联系作者...

20140

扫码关注云+社区

领取腾讯云代金券