Log Levels
Log levels classify messages by severity so operators can control verbosity and prioritize problems. In a Java backend, choosing levels consistently helps developers diagnose failures without overwhelming production logs.
A log level describes how important a log event is. Common levels in Java logging systems include `DEBUG`, `INFO`, `WARN`, and `ERROR`; some frameworks also provide `TRACE` and `FATAL` or similar levels. The exact names and behavior depend on the logging framework.
`DEBUG` is mainly for detailed diagnostic information useful during development or troubleshooting. `INFO` records normal application events that help explain what the system is doing, such as successful startup or completion of an important operation.
`WARN` indicates an unexpected or potentially problematic condition that does not necessarily prevent the operation from succeeding. `ERROR` indicates a failure or significant problem, often accompanied by an exception or other diagnostic context.
Logging configuration can filter events by severity. For example, with a threshold of `INFO`, `INFO`, `WARN`, and `ERROR` events can be emitted while `DEBUG` events are suppressed. This lets production systems reduce noise while retaining important operational information.
Good logging also depends on useful context. Messages should identify the relevant operation and include appropriate identifiers or state, while avoiding secrets, passwords, tokens, and other sensitive data.
Key points
- Use `DEBUG` for detailed troubleshooting information.
- Use `INFO` for significant normal application events.
- Use `WARN` for conditions that deserve attention but are not necessarily failures.
- Use `ERROR` for failed operations or serious problems.
- Configured thresholds can suppress lower-severity messages and reduce log volume.
Interview questions
What are log levels and why do we use them?
Log levels classify log events according to their severity or diagnostic importance. Common levels include `DEBUG`, `INFO`, `WARN`, and `ERROR`. They allow logging systems to filter messages so production environments can keep important events while suppressing excessive detail. Consistent use also helps operators quickly identify serious problems.
When would you use DEBUG, INFO, WARN, and ERROR?
I would use `DEBUG` for detailed information primarily useful while diagnosing behavior. `INFO` is appropriate for important normal events such as application startup or completion of a significant workflow. `WARN` is for unexpected conditions that do not necessarily mean the operation failed. `ERROR` is for significant failures that require investigation or intervention.
How does a log-level threshold affect what gets emitted?
A logging threshold determines which severity levels are enabled for a logger or handler. For example, an `INFO` threshold generally allows `INFO` and more severe events while excluding `DEBUG` events. The exact filtering model depends on the logging framework and configuration. This is useful for controlling production log volume without changing application code.
What makes a log message useful in a production Java service?
A useful message explains what happened and provides enough context to diagnose the event. Depending on the system, that context can include an operation name, relevant identifiers, or structured fields. Sensitive information such as credentials and access tokens should not be logged. The level should also match the operational significance of the event so important failures are not buried in noise.
Why can incorrect log-level choices cause operational problems?
If routine events are logged too aggressively, log volume and storage costs can grow and important signals can become difficult to find. If failures are logged at an insufficient level, monitoring and incident response may miss them or assign them the wrong priority. Excessive logging can also expose sensitive data. A good logging strategy therefore considers severity, diagnostic value, observability requirements, and data protection.