Logging / Observability

Request and response logging in Spring Boot microservices

Spring Middleware provides structured request and response logging for Spring Boot microservices. It uses a built-in RequestLoggingFilter with configurable logging behavior, response time tracking, URL exclusions, and forced logging for targeted debugging.

Explore logging See communication

Request logging Response logging Response time tracking URL exclusions Forced logging Observability patterns

What logging means here

Logging is not just a framework toggle. Spring Middleware provides a platform-level request and response logging model with explicit controls for enablement, exclusions, response timing, and incident-focused overrides.

Centralized request and response logging behavior
Explicit configuration under middleware.log
Operational controls for production debugging
Consistent behavior across services

Main runtime component

The built-in RequestLoggingFilter is the main integration point. It reads the logging properties, decides whether a request should be logged, handles exclusions, and emits request and response entries when applicable.

Configuration class: MiddlewareLogProperties
Filter: RequestLoggingFilter
Prefix: middleware.log

High-level logging flow

The logging path is simple and explicit: evaluate configuration, skip excluded requests, capture request and response data when allowed, and optionally measure response time.

Logging properties

All logging controls live under middleware.log. These properties define whether request logging, response logging, response time measurement, exclusions, and forced logging are enabled.

Example configuration

middleware:
  log:
    request:
      enabled: true
    response:
      enabled: true
    responseTime:
      enabled: false
    exclude:
      url-patterns:
        - /actuator/**
    apiKey: ${LOGGING_API_KEY:my-support-key}

Key properties

middleware.log.request.enabled — request logging
middleware.log.response.enabled — response logging
middleware.log.responseTime.enabled — response timing
middleware.log.exclude.url-patterns — excluded paths
middleware.log.apiKey — forced logging key

RequestLoggingFilter behavior

The filter does more than print messages. It applies exclusions, avoids known problematic bodies, respects logger level checks, and conditionally measures response time.

Evaluate request logging

Request logging is emitted when request logging is enabled and the logger can write at INFO level.

Apply exclusions and safety checks

Excluded URL patterns, multipart requests, and actuator paths are skipped or handled conservatively.

Emit response details

Response logging includes status and, when available, body details plus optional response time.

Request logging

When enabled, the filter logs the request line and, when possible, the request body.

Response logging

When enabled, the filter logs the response status and, when possible, the response body.

Response time logging

Response time can be appended when enabled through configuration and the runtime response-time toggle.

Exclusions and runtime safeguards

The logging model is intentionally defensive. It avoids unnecessary or risky body inspection for specific request types and infrastructure endpoints.

Excluded paths

Ant-style patterns defined in middleware.log.exclude.url-patterns are evaluated by the filter's skip logic.

/actuator/**
Other sensitive or noisy operational endpoints

Safety checks

Multipart requests: body reading is avoided
Actuator paths: skipped explicitly
Logger gating: INFO logging still depends on logger configuration

Forced logging for incident debugging

Spring Middleware supports a targeted override for a single request. This makes it possible to capture request and response logs during a live incident without changing the application's global logging level.

Header example

X-Logging-Key: my-support-key

Why it exists

In production you often cannot raise log verbosity globally. Forced logging provides a targeted mechanism for collecting a single request/response pair during incident analysis.

How it works

If the request header value matches middleware.log.apiKey, logging for that request is forced.

Logger-level bypass

Forced logging bypasses the normal INFO-level guard by emitting through an internal fallback path when necessary.

Operational scope

The mechanism is intended for targeted support and incident debugging, not for normal traffic capture.

Security and operational guidance

Forced logging is useful, but it must be treated as an operational capability with clear security boundaries.

Treat the key as a secret

Store middleware.log.apiKey in a secure configuration source and rotate it periodically.

Protect sensitive endpoints

Use exclude.url-patterns for paths involving credentials, payment data, or regulated personal information.

Prefer short-lived support workflows

A time-limited support path or gateway-injected header is safer than a long-lived static debugging key.

Operational alternatives

Forced logging is useful when you need raw request and response payloads, but it is not the only observability tool in the platform.

Use tracing and metrics first

In many cases, metrics, request identifiers, and distributed tracing are enough to identify the failing path without capturing payload bodies.

Use forced logging selectively

When raw payload visibility is required, enable it only for the minimum scope necessary and prefer redaction where possible.

Where to look in the code

The request and response logging behavior is implemented in a small set of platform classes.

LogRequestResponse

app module

.../middleware/log/LogRequestResponse.java

RequestLoggingFilter