Effective Logging Practices and Standards for Java Backend Systems

Logging quality directly impacts the speed of locating problems in production systems; ineffective logs force developers to rely on time‑consuming code reviews.

The article first asks three guiding questions: the purpose of logging, what constitutes effective logs, and the principles for logging.

It emphasizes that logs should capture user actions and system state, aid in early risk detection, and ultimately enable quick fault isolation.

Common log levels (FATAL, TRACE, ERROR, INFO, WARN) are described, highlighting their appropriate usage and the importance of avoiding misuse, such as logging stack traces at INFO level.

Four practical rules are proposed: (1) the whole team, including operations, must have clear log‑level standards; (2) never emit useless logs that drown out important information; (3) regularly review and improve log content; (4) formalize log format, size, and rotation policies.

Best‑practice steps for log maintenance include defining unified INFO/DEBUG (or TRACE) formats, conducting periodic log reviews, continuously optimizing logs based on incident analysis, and ensuring operations or testing teams promptly report log‑detected issues.

The article presents a concrete logging practice from an account team: consolidating logs into categorized files (info.log, error.log, sql_info.log, api_info.log, rpc_info.log) and recording request parameters, traceId, client IP, response data, and processing time.

TraceId is introduced as a unique identifier that ties together all logs generated by a single request, enabling simple retrieval of the full request trace in ELK; it can be injected via SLF4J MDC in an AOP layer without invasive code changes.

With traceId, locating a problem involves two steps: (1) query the API log for business‑critical keywords to find the original request/response; (2) use the traceId to pull all related logs, revealing key steps, RPC calls, and error details.

Finally, the article describes a real‑time log‑based monitoring and alerting system built by the operations team, where Filebeat streams logs to a monitoring platform that supports flexible alert rules (email, SMS, phone) for ERROR‑level events and also for high‑frequency INFO‑level warnings such as slow RPC calls.

The summary reiterates the four standard operations for logging: clear level definitions, no useless logs, regular content optimization, and standardized format/rotation policies.