Use logback filter to filter a class and mask a class

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.