How to Slim Down Your Application Logs by Up to 80%

1. Background

In everyday development we often print many INFO‑level logs for debugging and troubleshooting. As traffic grows, a single day's log file can exceed size thresholds (e.g., 5 GB), triggering alerts and consuming resources during retrieval, collection, and cleanup.

This article discusses common strategies for log slimming, using a concrete case study as illustration.

2. Log Slimming Methodology

2.1 Print Only Necessary Logs

During testing, many INFO logs are added temporarily. Before production, non‑essential logs should be removed or downgraded to DEBUG.

When a log could be either INFO or DEBUG, you can dynamically promote DEBUG logs to INFO via a context switch. Example pseudocode:

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

This allows logs that are normally DEBUG to appear as INFO when needed, distinguished by a prefix such as 【debug2info】.

2.2 Merge Logs

Logs that are printed before and after the same method can be merged into a single entry.

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

can be combined as:

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

2.3 Simplify, Abbreviate, Compress

When a log is necessary but its payload is large, consider:

Printing only the object's ID.

Creating a lightweight log‑specific DTO that contains only key fields.

Using abbreviations (e.g., write → w, read → r) or short identifiers (e.g., S1, S2) for repetitive names.

3. Optimization Case Study

3.1 Scenario Description

A business flow involves many beans that inherit from a common abstract class, which logs the item count before and after each bean execution. The final bean logs the result object.

3.2 Optimization Analysis

3.2.1 Print Only Necessary Logs

Since the "before" log of a bean is equivalent to the "after" log of the previous bean, keep only the after log and downgrade the before log to DEBUG.

Log only when the size changes:

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

This reduces redundant logs when sizes remain unchanged.

3.2.2 Log Merging

Store the pre‑execution size in memory and include it in the post‑execution log, merging the two entries:

log.info("service:{}, before size:{}", getName(), sizeBefore);
log.info("service:{}, after size:{}", getName(), sizeAfter);
// merged version
log.info("service:{}, before size:{}, after size:{}", getName(), sizeBefore, sizeAfter);

3.2.3 Log Simplification

Convert the result object (e.g., XXDTO) to a lightweight log object containing only essential fields such as id and title:

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

3.3 Effect Evaluation

The original logs generated about 5 GB per day, with ~80 % coming from size logs and ~10 % from final results. After applying the above techniques, daily log volume dropped to under 1 GB, achieving a substantial reduction while still supporting troubleshooting.

4. Conclusion

Log slimming requires balancing the need for diagnostic information with storage and performance constraints. Deleting unnecessary logs, merging related entries, and simplifying payloads are effective ways to achieve this balance.

Additional tricks, such as temporarily promoting DEBUG to INFO at runtime (or using tools like Arthas), can further aid debugging without inflating log size.