logback自定义appenderpolicy实现日志打印的逻辑处理

Posted 2021-04-24 爪哇之路

以下只贴出核心代码，运行代码详见

https://github.com/GloryXu

背景

目前所在的一个组为api接口平台，需要对注册上的接口进行相应的性能监控。因为是中途接手的项目，对于接口性能的监控比较好奇，就花了点时间了解下，又学了一手，写了个例子，记录下。

代码结构概览

文件名	说明
LogbackMain	应用main启动类
LogPrint	业务类（需要打印日志的类）
HandleAppender	logback中自定义的appender处理类
MyPolicy	自定义处理策略

HandleAppender类说明

 
   
   
 

  
    
    
  
 // 注意：这边的属性名一定要与logback.xml中的标签名一致
  
    
    
  
 private MyPolicy myPolicy;
  
    
    
  
 // 同上
  
    
    
  
 private Layout<E> layout;
  
    
    
  


  
    
    
  
 public void start() {
  
    
    
  
 super.start();
  
    
    
  
 if (this.layout == null) {
  
    
    
  
 this.addStatus(new ErrorStatus("No layout set for the appender named \"" + this.name + "\".", this));
  
    
    
  
 }
  
    
    
  
 }
  
    
    
  


  
    
    
  
 @Override
  
    
    
  
 protected void append(E eventObject) {
  
    
    
  
 if (this.myPolicy != null) {
  
    
    
  
 this.myPolicy.handler(this.layout.doLayout(eventObject));
  
    
    
  
 }
  
    
    
  
 }
 
   
   
 

• 类属性名与xml配置的标签名相同是一个注意点，否则appender类中的属性值为 null

LogPrint类说明

 
   
   
 

  
    
    
  
 protected static final Logger mylogger = LoggerFactory.getLogger("myLogger");
  
    
    
  


  
    
    
  
 private AtomicInteger count;
  
    
    
  


  
    
    
  
 public LogPrint(AtomicInteger count) {
  
    
    
  
 this.count = count;
  
    
    
  
 }
  
    
    
  


  
    
    
  
 private ScheduledThreadPoolExecutor pool = new ScheduledThreadPoolExecutor(1);
  
    
    
  


  
    
    
  
 public void printInfo () {
  
    
    
  
 pool.scheduleAtFixedRate(() -> {
  
    
    
  
 mylogger.info("print count " + count.incrementAndGet());
  
    
    
  


  
    
    
  
 mylogger.debug("print debug level log!");
  
    
    
  
 }, 1000, 5000, TimeUnit.MILLISECONDS);
  
    
    
  
 }
 
   
   
 

以上使用一个定时线程池固定频率模拟业务系统打印日志，触发日志定制化处理功能

MyPolicy类说明

该类比较简单，不再说明 详细可查阅 Github代码

logback.xml配置说明

 
   
   
 

  
    
    
  
 <appender name="myLog" class="com.redsun.logback.HandleAppender">
  
    
    
  
 <!--A.根据设置过滤日志，此处设置的是info-->
  
    
    
  
 <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
  
    
    
  
 <level>INFO</level>
  
    
    
  
 </filter>
  
    
    
  
 <!--B.自定义设置处理策略-->
  
    
    
  
 <myPolicy class="com.redsun.logback.MyPolicy">
  
    
    
  
 <appName>monitor</appName>
  
    
    
  
 </myPolicy>
  
    
    
  
 <!--日志打印格式，m：message-->
  
    
    
  
 <layout class="ch.qos.logback.classic.PatternLayout">
  
    
    
  
 <pattern>%m</pattern>
  
    
    
  
 </layout>
  
    
    
  
 </appender>
  
    
    
  
 <!--C.设置日志级别为info-->
  
    
    
  
 <!--additivity=true，表示将日志输出出来，false则不会输出日志，但是appender仍可接收到输出的日志message-->
  
    
    
  
 <logger name="myLogger" level="info" additivity="true">
  
    
    
  
 <!--指定自定义的appender来处理-->
  
    
    
  
 <appender-ref ref="myLog"/>
  
    
    
  
 </logger>
 
   
   
 

需要注意的点都已在xml注释中说明，此处不再赘述

运行情况

在打印日志前都会将需要打印的日志发送至 MyPolicy来的 handle中处理一下，此时的逻辑就可以自定义了

缺点

我们项目的运用是在 handle中将打印的日志（接口的运行耗时，成功率等等）发送至 redis中，然后会有另外的项目去定时任务的获取数据并作计算，最终算出这个接口的运行情况。

那么有什么缺点呢，通过上面打印可以发现，打印的线程和真实跑业务的线程是同一个，如果自定义的日志处理逻辑没有任何的阻塞操作就还好，但是一旦有了耗时比较长的操作就会影响接口的性能了，遇到这种问题不熟悉的人往往很难定位到问题是如何产生的。可以根据业务需求，或者真实场景实现异步化处理也未尝不可，当然也要注意资源的分配和控制，不然因为次要功能影响了主要的业务功能就得不偿失了。