Please consider decoupling log rotation and log compression to save VM sites from log spikes

[Zugschlus]

Hi,

this is a suggestion for an enhancement.

A typical logrotate run has two phases: One where the actual log rotation takes place, and a second phase when newly rotated logs get compressed.

The first is somewhat time critical, since sites want their log rotation to be in sync as far as possible (makes log corelation way easier). This phase is rather easy on CPU and disk since rename operations are cheap.

The second phase is CPU intensive, which causes a visible load spike in virtualized environments. Sites thus have the desire to spread this phase out across the VMs so that not all VMs do the compression at once.

It is not currently possible to have log rotation synchronous without causing the load spike of phase B. If a site decides to spread log rotation randomly or semi randomly (I have seen sites chosing the minute of log rotation by taking the modulus of the machine Id or the IP address by minutes), the log rotation is not synchronized. If a site decides to run log rotation on all machines at the same time, we have the load spike.

Please consider implementing one of the following two features to allow sites to have both:

--compressonly and --nocompress

Implement two options --compressonly and --nocompress which will either not run a compression process even if requested by configuration (--nocompress) or just run the compression of the highest numbered uncompressed log generation (--compressonly). This way, sites could run two different cron jobs for doing the actual rotation (all at once) and compression (staggered)

configuration file option

Implement a configuration file option "sleepbeforecompress", taking one or two integer parameters. If one parameter, logrotate would sleep the exact number of seconds before beginning the compression stage. If two parameters, logrotate would randomly choose a waiting time between the two numbers, for example, sleepbeforecompress 0 3600 would sleep a random time up to one hour.

This could be a global configuration option or a per-file configuration option.

While I prefer this option, I do understand that this would mean bigger changes to logrotating code. Probably, the current code to compress should be replaced by building a list of files that should be rotated, paired with the time rotation should begin, with compression happening last in a loop.

Please consider implementing this. Sites running big numbers of systems in a virtualized environent would love that.

Greetings
Marc

[kdudka]

If you can use two cron jobs, why cannot you use two config files for logrotate? The first would rotate log files, the second would compress the already rotated ones.

[Zugschlus]

How would a logrotate config file that does only compression look like?

Having two logrotate config files would integrate just horribly with every distribution that I am aware of.

[kdudka]

I thought you needed it for some custom configuration of logrotate. I do not think we could support it at a distribution level. And yes, logrotate sounds like an overkill for the second job. I think something like this could work:

$ find /var/log -type f -name '*[0-9]' -ls -exec gzip '{}' \;

[Zugschlus]

That would override semantics of the delaycompress directive and probably compress logs prematurely. I'd rather not break delaycompress semantics this way.

[kdudka]

Yes, it is not compatible with delaycompress or even compress. So the solution is to avoid these options to keep it working. There always needs to be some trade-off when micro optimization is involved.