Logrotate container

A solution for when log shipping is out of the question.

More information

Have you ever found yourself unable to use log shipping, for any number of reasons? Maybe you have an older project, or maybe the team has simply decided that log files are the approach that they'd like to use. Well, you're going to have a problem - some days, weeks or months down the line, the server disk space is going to run out because of all of the log output, or you'll end up with log files that are hundreds of MB or even GB in size and thus hard to browse.

What I did

I solved that by creating a container of Logrotate, which could then use bind mounts for input and output directories of logs. It would run alongside an application and, when scheduled, would take the log files, empty their contents without deleting the file itself (in case it's still open for writing), would compress the extracted contents into an archive and move it to the output directory.

What I learnt

This actually worked surprisingly nice. Not only that, but using containers for this meant that I could have dozens of instances running in parallel, each with different configuration, with basically no risk of them getting in the way of one another. The resource usage was low, but the utility great.

This allowed me to go from hundreds of MB per day in logs down to just a few dozens of MB after compression.