Logback filter filters a class and masks a class
Using logback to configure log files, sometimes we need to filter or screen the logs of a class, which can be realized by the following methods
Add dependent packages required by janinoeventevaluator
<!-- https://mvnrepository.com/artifact/org.codehaus.janino/janino -->
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>janino</artifactId>
<version>3.1.2</version>
</dependency>
Add corresponding filter conditions to logback
<appender name="FILE_ERROR">
<filter>
<evaluator>
<expression>logger.contains("UserController")</expression>
</evaluator>
<OnMismatch>NEUTRAL</OnMismatch>
<OnMatch>DENY</OnMatch>
</filter>
............
</appender>
In the statement < expression >, it means whether the logger name contains usercontroller and returns a Boolean value. When < onmatch >, log recording is not performed
Application of logback filter
I’ve been collecting business data recently. There is a problem, that is, how to capture the required business data by logging (what I need here is the JSON format data of an object). We know that if logs are recorded in the form of log.info, although we can write multiple Appenders to output info level log information to two different files, there will also be other info level log information in the file recording business data. So how to filter? Logback filter is used.
Logbackfilter introduction
Lockback’s filter can filter the contents of the log, and then return an enumeration class of type filterreply. So as to filter out the unqualified log information.
Logback provides two types of filters: one is regular filter; The other is turbo filter.
Regular filter is mainly applied to the appender and only works at the appender level. A regular filter instance chain can be bound to the appender instance. Regular filter inherits and implements the “ch.qos.logback.core.filter.filter” class. To customize your own regular filter, you need to inherit the ch.qos.logback.core.filter.filter class and implement the decision () method.
The turbofilter object is bound to the logging context. Therefore, they are not only called when a given appender is used, but also a logging request is issued every time. Their range is wider than the filters attached to the appender. More importantly, they are called before the loggingevent object is created. The turbofilter object does not need to instantiate logging events to filter logging requests. Therefore, turbo filters are designed for high-performance filtering of recorded events, even before creating events. To implement this type of filter, you need to inherit ch.qos.logback.classic.turbo.turbofilter; Class specific implementation can refer toLogback official website – Filter Implementation。
Custom regular filter
Since my business is a log with pointer to info level, it is not necessary to implement the global turbofilter. Only the implementation of regular filter is given here
The following is the class code
package com.qf58.srm.pub;
import ch.qos.logback.classic.spi.ILoggingEvent;
import ch.qos.logback.core.filter.Filter;
import ch.qos.logback.core.spi.FilterReply;
/**
* @Author: WangZhan
* @Description:
* @Date Created in 11:53 2018/7/26.
*/
public class BdLogMessageFilter extends Filter<ILoggingEvent> {
@Override
public FilterReply decide(ILoggingEvent iLoggingEvent) {
if (iLoggingEvent.getMessage() != null && iLoggingEvent.getMessage().startsWith("{") && iLoggingEvent
.getMessage().endsWith("}")){
return FilterReply.ACCEPT;
}
return FilterReply.DENY;
}
}
The following is the logback configuration
Finally, run your own program to see the printing effect.
The above is my personal experience. I hope I can give you a reference, and I hope you can support developpaer.