Filtering Specific Noise from Spring Boot Logs

Where the Problem Started

More logs are not automatically better. When too much noise is mixed in, the errors and request flows that matter become harder to see. This post records how I filtered specific Spring Boot logs and why reducing log noise is part of operational readability.

When too many logs pile up in Spring Boot, it can be inconvenient when you want to search through logs to find errors. Or, if logs are being accumulated in AWS CloudWatch where maximum throughput is fixed, critical problems such as missing logs can occur.

Especially when there are additional side logs after deploying to Kubernetes or ELB, not only logs generated by Spring Boot itself, it can be reasonable to decide not to leave some logs.

Here is a simple way to exclude the logs you want.

Implementation Path

import ch.qos.logback.classic.spi.ILoggingEvent
import ch.qos.logback.core.filter.Filter
import ch.qos.logback.core.spi.FilterReply

class ContentBasedFilter : Filter<ILoggingEvent>() {
    override fun decide(event: ILoggingEvent): FilterReply {
        val message = event.formattedMessage
        if (message.contains("/manage/health") ||
            message.contains("kube-probe") ||
            message.contains("ELB-HealthChecker")) {
            return FilterReply.DENY
        }
        return FilterReply.NEUTRAL
    }
}

ch.qos.logback.classic.spi.ILoggingEvent is an interface in Logback, and it contains all data related to logging.

ch.qos.logback.core.filter.Filter is an abstract class in Logback, and it is used simply to filter logging events.

ch.qos.logback.core.spi.FilterReply is an enum, and you can choose DENY(exclude the event), ACCEPT(log the event), or NEUTRAL(do nothing).

In the code, logging related to the Spring Boot health check endpoint /manage/health, logging related to kube-probe for Kubernetes deployment, and ELB-HealthChecker logs related to ELB deployment are excluded with the DENY option.

ContentBasedFilter is not a @Configuration or @Bean, so it has to be added to an xml configuration file. That file is logback-spring.xml.

<configuration>
    <springProperty scope="context" name="application-logging" source="spring.application.name" defaultValue=""/>

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <!-- Translated pattern from your application.yml -->
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%5p] [${SPRING_APPLICATION_NAME:-},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-}] [%15.15t] %-40.40logger{39} : %msg%n%replace(%ex){'\n','\r'}</pattern>
        </encoder>
        <!-- Apply the custom filter -->
        <filter class="${파일 디렉토리).ContentBasedFilter"/>
    </appender>

    <root level="INFO">
        <appender-ref ref="STDOUT"/>
    </root>
</configuration>

Logging Takeaway

Log filtering should not hide problems; it should make important signals easier to see. Before removing a log, it is worth asking whether it is needed for incident analysis, whether it repeatedly produces noise, and whether the same signal is available through metrics or traces.

This is the basic format. The path to the file created earlier was added to filter class, and SPRING_APPLICATION_NAME, traceId, spanId, and so on were added to pattern from application.yaml for additional custom logging.