Log Levels and Severity Filtering

Log levels classify events by severity and help control which messages are emitted. They let Java services balance useful diagnostic detail against log volume, processing overhead, and storage costs.

A log level is a severity classification attached to a log event. Common levels include `TRACE`, `DEBUG`, `INFO`, `WARN`, and `ERROR`, with increasing severity from detailed diagnostic information toward failures or serious problems.

Severity filtering determines whether a logging event is emitted by comparing its level with the configured threshold. For example, an `INFO` threshold normally permits `INFO`, `WARN`, and `ERROR` events while suppressing `DEBUG` and `TRACE` events.

In a Java backend, the application usually writes logs through a logging API such as SLF4J, while a concrete logging implementation handles configuration and output. Configuration can often assign different thresholds to different packages or components, which is useful when debugging one subsystem without increasing verbosity everywhere.

Choosing levels consistently makes logs easier to search and operate. `DEBUG` and `TRACE` are generally intended for diagnostic detail, `INFO` for significant normal operation, `WARN` for unusual conditions that do not necessarily indicate failure, and `ERROR` for failures requiring attention. Exact semantics can vary by logging framework and team conventions.

Filtering is also important for performance and cost. Suppressed messages avoid unnecessary output, but expensive message construction can still occur if values are calculated before the logging call; parameterized logging and appropriate level checks can help avoid that work.

Key points

• Higher severity thresholds reduce diagnostic detail and log volume.
• A typical ordering is `TRACE` < `DEBUG` < `INFO` < `WARN` < `ERROR`.
• An `INFO` threshold normally allows `INFO`, `WARN`, and `ERROR`.
• Logging APIs such as SLF4J can separate application code from the logging implementation.
• Use parameterized logging to avoid unnecessary string construction when a level is disabled.

Interview questions

What are common log levels, and when would you use them?

Common levels include `TRACE`, `DEBUG`, `INFO`, `WARN`, and `ERROR`. `TRACE` and `DEBUG` provide diagnostic detail, while `INFO` records important normal application events. `WARN` indicates an unusual condition that may need investigation, and `ERROR` indicates a failure or significant problem. Teams should define consistent semantics so operators can interpret logs reliably.

If the configured logging level is `INFO`, which common levels are normally emitted?

With a conventional severity ordering, `INFO`, `WARN`, and `ERROR` events are emitted. `DEBUG` and `TRACE` events are filtered out. The exact behavior depends on the logging framework and configuration, but this threshold is commonly used to suppress detailed diagnostic messages while retaining operationally important events.

Why should Java applications use parameterized logging instead of string concatenation?

Parameterized logging lets the logging framework defer formatting until it knows the event will actually be emitted. With string concatenation, expressions can be evaluated and a string can be constructed even when the configured level suppresses the message. This can reduce unnecessary CPU and allocation costs. It also makes structured logging calls clearer and easier to maintain.

How would you configure detailed logging for one Java package without enabling it for the whole application?

I would configure a logger for the target package and assign it a more verbose threshold, such as `DEBUG`. The application's broader logger can remain at `INFO` so unrelated components continue producing normal operational volume. Logger hierarchies commonly allow package-specific configuration to override or refine inherited settings. The exact configuration syntax depends on the logging implementation and deployment setup.

What factors would you consider when choosing log levels in a production service?

I would consider operational usefulness, expected event frequency, troubleshooting requirements, performance, storage costs, and the sensitivity of the data being logged. Normal business milestones generally belong at `INFO`, while high-volume diagnostic details should usually remain below that threshold. Warnings and errors should be actionable enough to support investigation without turning routine conditions into apparent incidents. I would also establish consistent conventions and review logs for secrets or other sensitive data.