Order (high priority to low):
- FATAL · ERROR · WARN · INFO · DEBUG · TRACE
DEBUGfor fine‑grained diagnostic messages that help you trace flow and variable values. These should never appear in production – set your root logger toINFOor higher to silence them. In your code:logger.debug("Processing request id={}", id);INFOfor normal, informative messages that mark significant application events (startup, shutdown, important state changes). Think of it as a “verbose” mode. Example:logger.info("Connection pool initialised with {} threads", poolSize);WARNfor potential issues that do not stop the application from functioning. Use it when you fall back to a default, or when a deprecated API is called. The system carries on without a problem.logger.warn("Configuration key 'max.retries' missing – defaulting to 3");ERRORfor application errors that still allow the application to hobble along. These indicate a real problem – an exception caught, a service call failed, but the operation can be retried or the user can continue. Like a missing admin‑supplied config value that falls back to a hard‑coded default.logger.error("Unable to reach inventory service, using cached prices", ex);FATALfor critical failures, after which the application quits abnormally. After logging a fatal message, the system is considered dead. For example, in Log4j2:logger.fatal("Database connection pool exhausted, aborting.");
- ALL – enables every log statement, regardless of its level. Handy for temporarily debugging a specific component, but never for production.
- OFF – disables all logging output. Use it to silence a noisy logger completely.