Logging Best Practices.

Hook: In production, logs are your app’s black box recorder: when something breaks at 2 a.m., they are often the fastest way to see what really happened.

Question: What are logging best practices in Spring Boot?

Answer: Good logging means writing messages that help you debug real problems without slowing the app down or leaking secrets. In Spring Boot, you should log at the right level, keep messages short but useful, add request context like a correlation ID, and avoid logging passwords, tokens, or large payloads. The goal is to make production issues easy to trace while keeping logs cheap, safe, and searchable.

Interview-Ready Answer: I treat logging as a production debugging tool, not a place to dump everything. In Spring Boot, I use the right log level, parameterized messages like log.info('orderId={}', id), and a correlation ID in MDC so one request can be traced across services. I also avoid sensitive data and duplicate stack traces, because clean, structured logs are much more useful than noisy ones.

What logging should do

Detailed Explanation: A good log answers three questions fast: what happened, where it happened, and how to trace it. Spring Boot gives you a logging stack out of the box, usually SLF4J as the logging API and Logback as the default implementation, so your code should focus on message quality and context, not on low-level plumbing.

How it works under the hood

1. A request enters your app, often through a filter or interceptor.
2. You create or read a correlation ID (a shared request identifier) and store it in MDC (Mapped Diagnostic Context, a per-thread key-value map used by the logger).
3. Your controller and service classes log with placeholders such as {}, so strings are built only when needed.
4. Exceptions are logged once at the boundary where they are handled, usually in a controller advice or global error handler.
5. The logging framework formats the event, adds time/thread/level data, and writes it to console, file, or JSON output.
6. A log shipper or platform tool sends those logs to a central place where you can search by correlation ID, user, order, or trace.

Best practices that matter in real production

• Use the right level: ERROR for failures, WARN for suspicious but recoverable events, INFO for business milestones, and DEBUG for detailed diagnostics you may turn on briefly.
• Prefer parameterized logging: log.info('orderId={}', id) is better than string concatenation because the message is not fully built when the level is disabled.
• Log at boundaries: log once when a request starts, when a key business action succeeds or fails, and when an exception is handled. Do not log the same failure in every layer.
• Avoid secrets and sensitive data: never print passwords, JWTs, API keys, card numbers, or full personal data. If you need identifiers, log a masked version.
• Make logs searchable: include stable fields such as orderId, userId, and correlationId so you can filter quickly.

Good format choices

Performance and edge cases

Logging is usually O(1) work per event from your code’s perspective, but the real cost is I/O: writing to disk, console, or a remote sink. A single line may take microseconds in memory but much longer if it blocks on a slow appender. That is why high-volume systems often use async logging, which puts events into a queue and writes them on another thread.

Spring Boot’s default root level is typically INFO, which is a safe production default. Be careful with DEBUG in hot paths, loops, or high-traffic endpoints: a tiny message printed 5,000 times per second becomes a real outage when the log volume explodes. Also remember that MDC is thread-local, so context does not automatically flow into new threads, async executors, or reactive pipelines unless you propagate it deliberately.

Memory hook: think of logging like a black box recorder, not a diary — record the flight, not every thought in the cockpit.

Real-World Story: Imagine a checkout service in an e-commerce app. Each request gets a correlation ID, the service logs orderId, payment status, and timing, and the exception handler logs stack traces only for unexpected failures. When production is healthy, engineers can search one correlation ID and reconstruct the whole request across gateway, checkout, and payment services.

Now the bad version: a developer leaves very noisy DEBUG logs on in production and logs the full request body for every checkout. Traffic spikes during a sale, log volume explodes, disk usage climbs, pods restart, and customers start seeing checkout failures. In the incident review, the symptoms are obvious: repeated log lines, no useful request IDs, and a log platform that is full of noise instead of clues. That is why best practices are not cosmetic; they directly affect uptime, cost, and incident response speed.

Follow-up & Tricky Questions:

• How do you choose between INFO, WARN, DEBUG, and ERROR? I use INFO for business milestones, WARN for recoverable problems, DEBUG for deep diagnostics, and ERROR only when the system cannot complete the action or needs urgent attention.
• Why are parameterized logs better than string concatenation? With placeholders, the logger can skip building the final string when that level is disabled, which saves CPU and garbage creation on busy paths.
• How do you add a correlation ID in Spring Boot? The common pattern is a filter or interceptor that reads a request header, generates one if missing, stores it in MDC, and clears it in finally so it never leaks to the next request.
• When should exceptions be logged? Usually at the point where they are handled, not at every catch block. If you log and rethrow at multiple layers, you get duplicate stack traces and noisy incidents.
• How do logging practices change with async or reactive code? MDC is thread-local, so it does not automatically follow work that moves to another thread. You need context propagation, or in reactive code you should use Reactor context-aware patterns.
• Should I log every request body and every SQL statement? No for production by default. Request bodies can expose secrets or create huge volumes, and SQL logging can be valuable in short debugging windows but is too expensive and noisy to leave on permanently.
• If I catch an exception, should I log it and then throw a new one? Usually no, unless you are adding useful context. If you do wrap it, keep the original cause and make sure only one layer emits the final stack trace.
• Is System.out.println okay in Spring Boot? It is fine for a quick local test, but not for real production because it lacks log levels, context, routing, and consistent formatting.

Common Mistakes:

• Logging too much: fix it by logging business events and failures, not every line of code or every loop iteration.
• Logging secrets: fix it by masking or omitting tokens, passwords, card data, and personal data.
• Logging the same exception multiple times: fix it by logging once at the boundary where the error is finally handled.
• No correlation ID: fix it by adding a request ID in MDC so one incident can be traced across services.

Memory Hook: Logs are the black box, not the diary. Keep enough detail to reconstruct the flight, but not so much that the recorder becomes the crash.

Cheat Sheet:

• Use INFO for important milestones, WARN for recoverable problems, ERROR for real failures.
• Prefer log.info("id={}", id) over string concatenation.
• Add a correlation ID with MDC and clear it in finally.
• Log exceptions once, close to the handling boundary.
• Never log secrets, tokens, passwords, or large raw payloads in production.
• Use JSON or structured fields when you need reliable searching at scale.

Practice Tasks:

• Add a second header, such as X-User-Id, to the MDC and include it in logs.
• Change the example to emit JSON-style logs and compare how easy it is to search.
• Trigger the 404 and bad-request paths and inspect how the correlation ID appears in both the response and the logs.