Log Reduction Techniques for Backend Systems

In daily development, developers often print many INFO‑level logs for debugging, which can cause log files to grow beyond thresholds (e.g., 5 GB) and lead to performance issues during log retrieval, data collection, and disk cleanup.

1. Print only necessary logs – Convert non‑essential INFO logs to DEBUG or remove them before production. When a log may need to be INFO for troubleshooting, a temporary switch can promote DEBUG logs to INFO at runtime, using a prefix such as 【debug2info】 to distinguish them.

if (log.isDebugEnable()) {
    log.debug(xxx);
} else if (TracerUtils.openDebug2Info()) {
    log.info("【debug2info】" + xxx);
}

2. Merge log entries – Combine multiple related INFO statements into a single line to avoid redundancy.

INFO   [64 traceId]   XXXService before size=10
INFO   [64 traceId]   XXXService after size=4

can be merged into:

INFO   [64 traceId]   XXXService before size=10 after size=4

3. Simplify, abbreviate, and compress – Log only identifiers instead of full objects, create lightweight DTOs for logging, or use short abbreviations (e.g., w for write, r for read) and numbered bean references (S1, S2) to reduce payload.

Log only the ID of an object.

Create a dedicated log DTO containing only key fields.

Use abbreviations or numeric aliases for repetitive terms.

Optimization case study

In a pipeline with many beans inheriting from an abstract class, the original implementation logged size before and after each bean, resulting in ~5 GB of logs per day, 80 % of which were size logs.

1. Print only necessary logs – Skip logging when sizeBefore == sizeAfter :

if (sizeBefore != sizeAfter) {
    log.info("service:{}, 前size:{},后size:{}", getName(), sizeBefore, sizeAfter);
}

2. Merge logs – Record the before size in memory and log both before and after in a single statement:

log.info("service:{}, 前size:{},后size:{}", getName(), sizeBefore, sizeAfter);

3. Simplify result logs – Convert result objects to a lightweight DTO before logging:

log.info("resultId:{}", result.getId());
// or
log.info("result:{}", toSimpleLog(result));

After applying these methods, daily log volume dropped to less than 1 GB while still providing sufficient information for troubleshooting.

Conclusion – Effective log slimming requires balancing the need for diagnostic information with log size; techniques such as removing unnecessary logs, merging entries, and simplifying messages can achieve substantial reductions.