Mastering Log Levels: Practical Guidelines for Effective Logging

Log Levels Overview

Common logging frameworks (e.g., SLF4J, Log4j, Logback) define four primary levels:

ERROR : Critical failure that cannot be recovered automatically; requires human intervention. Include stack trace and contextual data.

WARN : Recoverable anomaly (e.g., validation failure, unexpected return code). Should be monitored but does not stop normal flow.

INFO : Key runtime events such as configuration values, business‑process state changes, or important service interactions. Useful for operations and post‑mortem analysis.

DEBUG : Detailed diagnostic information (method parameters, return values, internal state). Verbose; typically disabled in production.

When to Write Logs

Write logs only for situations that aid troubleshooting or monitoring:

Runtime exceptions : Log at WARN or ERROR depending on severity.

Business‑process deviations : Record when inputs are invalid, return codes are out of range, or results differ from expectations.

Core component actions : Use INFO for user‑flow milestones, service calls, or database modifications; switch to DEBUG for high‑frequency internal details.

System initialization : Log startup parameters and successful component bootstrapping with INFO.

Performance Considerations

Log only when necessary : Excessive logging adds CPU, I/O, and storage overhead and can obscure real problems.

Static logger instances to avoid repeated creation costs:

private static final Logger logger = LoggerFactory.getLogger(MyClass.class);

Level checks in hot paths : Guard expensive log statements with if (logger.isDebugEnabled()) { ... } or use placeholder syntax.

logger.debug("Processing order {} for user {}", orderId, userId);

Avoid string concatenation in log calls; use parameterized messages to prevent unnecessary object creation.

Configure appropriate layouts to avoid logging data that is never consumed.

INFO and DEBUG Best Practices

Typical use cases

Online issue tracing – combine ERROR/WARN/INFO and enable DEBUG temporarily for fine‑grained details.

Scenario reconstruction – include session identifiers (IP, request ID) to rebuild user journeys across services.

Performance monitoring – log request handling time, module processing time, and latency of core components (DB, cache, I/O).

Recommended log fields

Timestamp with timezone and milliseconds.

Log level.

Session identifier (user, request ID, IP).

Functional identifier (method name or feature tag).

Concise message describing the event, status, and key parameters.

Optional extra data such as application version, thread ID, etc.

WARN and ERROR Best Practices

Use WARN for recoverable anomalies and ERROR for critical failures that impact business functionality.

WARN should be coupled with statistical alerting (e.g., Zabbix, custom scripts) to avoid alert fatigue.

ERROR alerts must be actionable: describe what happened, which functionality is affected, and where to find remediation information.

Typical ERROR template

log.error("[Interface] [Error description] occurs. [Possible cause]. [Suggested action] [params].");
log.error("[Interface] [Error description] occurs. [Possible cause]. Please contact xxx@xxx [params].");

Sample SLF4J Usage

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

private static final Logger logger = LoggerFactory.getLogger(MyClass.class);

SLF4J provides a façade; the actual logging implementation (Log4j, Logback, etc.) is plugged in via adapters, allowing seamless migration without code changes.

Reference Materials

https://www.slf4j.org/manual.html

http://logging.apache.org/log4j/2.x/