Root Cause Analysis and Resolution of Disk Usage Alert in a Java Application

1. How the problem was discovered Shortly after the Java system was deployed, an alarm indicated that disk usage had risen above 90% and continued to increase.

2. Impact of the problem The saturated disk prevented business logs from being written, severely affecting the system’s reliability.

3. Detailed troubleshooting process Initially the team suspected excessive log levels, but the business log files were small. By logging into the server via a bastion host, they inspected directories with high disk usage and found a large log4j.log in the root. Although the application uses Logback, the file contained the application’s own debug logs. Scanning all JARs revealed a third‑party JAR that bundled a log4j.xml with the root logger set to DEBUG and output directed to the root directory.

4. How the problem was solved The offending JAR was identified as an unnecessary transitive dependency. It was excluded in the Maven configuration, which removed the unwanted Log4j configuration and stopped the excessive log generation.

5. Summary and reflection When introducing third‑party JARs, always review their dependency scopes and potential conflicts. Avoid shipping debug configurations or test log files in production artifacts, and use Maven exclusions to prevent similar issues.