How to Slim Down Application Logs: Practical Techniques and Real‑World Case Study

Background

In everyday development, many INFO‑level logs are printed to simplify debugging and issue tracing. As traffic grows, a single day's log file can exceed thresholds (e.g., 5 GB), triggering alerts and consuming resources during log retrieval, data collection, and disk cleanup.

Log Slimming Methodology

1. Print Only Necessary Logs

Temporary INFO logs used for testing should be removed or downgraded to DEBUG before production. When a log may need to be INFO for troubleshooting but is usually DEBUG, a context flag can promote DEBUG logs to INFO at runtime.

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

Prefix such logs (e.g., 【debug2info】) to distinguish them from regular INFO entries.

2. Merge Duplicate Logs

When a method logs before and after execution, combine them into a single entry.

INFO [64-bit traceId] XXXService 执行前 size =10 INFO [64-bit traceId] XXXService 执行后 size =4

can be merged into:

INFO [64-bit traceId] XXXService 执行前 size =10 执行后 size =4

3. Simplify, Abbreviate, and Compress

Print only the identifier of a large object.

Create a lightweight log‑specific DTO that retains only key fields (e.g., id, title).

Use short abbreviations (e.g., w for write, r for read) or numbered placeholders (S1, S2) for repetitive bean names.

Optimization Case Study

Scenario

A business flow involves many beans inheriting from a common abstract class, each printing pre‑ and post‑execution information such as pipeline item counts. The final bean prints the result object.

Analysis and Refactoring

1) Print Only Necessary Logs

Since the pre‑execution log mirrors the previous bean's post‑log, keep only the post‑log and downgrade the pre‑log to DEBUG or remove it. Add a conditional check to skip logging when size before and after are equal:

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

This reduces redundant entries dramatically, especially when many beans produce identical size values.

2) Merge Logs

Store the pre‑size in memory and emit a combined log after execution:

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

3) Log Simplification

Convert result objects (e.g., XXDTO) into a lightweight log DTO containing only essential fields before printing:

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

Effect Evaluation

The original logs generated roughly 5 GB per day, with about 80 % consisting of repetitive size logs and 10 % of final result logs. After applying the above techniques, daily log volume dropped to under 1 GB, achieving an 80 % reduction while preserving necessary diagnostic information.

Conclusion

Log slimming requires balancing the need for troubleshooting information against storage and performance costs. Effective strategies include removing unnecessary logs, merging related entries, and simplifying log content. Advanced tricks such as context‑driven DEBUG‑to‑INFO promotion (or tools like Arthas) can further aid live debugging without inflating log size.