Introduction

In Spring Boot, “access logs” usually mean one log line per HTTP request emitted by the embedded web server. That is different from application logging inside controllers or filters. If all you need is request method, path, status, and timing, enabling the server’s access log is usually the cleanest approach.

Enable Access Logs on the Embedded Server

For the default embedded Tomcat setup, the basic properties look like this:

1server.tomcat.accesslog.enabled=true
2server.tomcat.accesslog.directory=logs
3server.tomcat.accesslog.pattern=%h %l %u %t "%r" %s %b %D
4server.tomcat.accesslog.prefix=access
5server.tomcat.accesslog.suffix=.log

This turns on Tomcat access logging and writes request lines to the configured directory. The pattern controls what appears in each line, such as:

• client address
• request line
• response status
• response size
• request duration

For many production services, this is enough and has the advantage of keeping request logging at the server layer instead of mixing it into business code.

Know What Access Logs Are Good For

Access logs are ideal for:

• request auditing
• coarse performance monitoring
• status-code analysis
• traffic troubleshooting

They are not the best tool for logging request bodies, controller-specific business fields, or structured application events. For those, use filters, interceptors, or explicit application logging.

Use a Filter for Request-Level Application Logging

If you want more control from inside the Spring application, a filter is a common option. CommonsRequestLoggingFilter is a lightweight starting point:

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3import org.springframework.web.filter.CommonsRequestLoggingFilter;
4
5@Configuration
6public class RequestLoggingConfig {
7
8    @Bean
9    CommonsRequestLoggingFilter requestLoggingFilter() {
10        CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter();
11        filter.setIncludeClientInfo(true);
12        filter.setIncludeQueryString(true);
13        filter.setIncludePayload(false);
14        filter.setIncludeHeaders(false);
15        filter.setAfterMessagePrefix("HTTP REQUEST: ");
16        return filter;
17    }
18}

This is not the same as a Tomcat access log. It runs in the application stack and is better suited to application-aware request logging.

Access Logs Versus Request Bodies

This distinction matters because many developers turn on access logs and then expect to see JSON request bodies. Server access logs normally do not log bodies. That is intentional, because bodies can be large, sensitive, and expensive to capture.

If you genuinely need body logging:

• use an application filter or interceptor
• be careful with privacy and secrets
• consider truncation rules
• avoid logging large payloads blindly

Access logs are for request metadata, not full traffic capture.

Include Correlation Information Deliberately

If your service uses request ids or tracing headers, make sure the access-log pattern or filter strategy includes the right correlation fields. Otherwise you will have request logs that are hard to connect to application logs and distributed traces.

For example, if a reverse proxy injects correlation headers, an application filter may be the easier place to copy those values into the logging context.

Container Choice Still Matters

Spring Boot can run on Tomcat, Jetty, or Undertow, and access-log properties differ by container. The example above is Tomcat-specific. That is one reason it helps to think of access logging as a server feature, not a universal Spring abstraction.

If the app is not using embedded Tomcat, check the matching server settings rather than assuming Tomcat property names will work.

Common Pitfalls

The most common mistake is confusing access logs with application logs. Access logs are generated by the web server and are mostly about request metadata, not domain behavior.

Another pitfall is enabling request-body logging casually. That can expose secrets, increase log volume, and create serious compliance problems if done without limits.

It is also easy to forget that property names are server-specific. A Tomcat example does not automatically apply to Jetty or Undertow.

Finally, request logging without correlation ids is often much less useful than expected. If the logs cannot be connected to the rest of the system, debugging remains slow even though the requests are technically logged.

Summary

• For standard request metadata, enable the embedded server’s access log first.
• On Tomcat, use server.tomcat.accesslog.* properties.
• Access logs are good for path, status, size, and timing, not full request bodies.
• Use filters or interceptors when you need application-aware request logging.
• Be deliberate about privacy, payload size, and correlation ids when designing HTTP request logs.