This is based on lp#1078213.
Apparently Juju does have log rotation internally now, after files reach 300M in size. However, on smaller environments this can still end up taking a large amount of disk. I'm working on an instance which only has an 8G disk, and /var/log/juju is taking roughly 1G of that - and individual logfiles within are taking between 51 and 183 MB of that. If I simply rely on Juju's file rotation here, these files can get quite a bit larger (and take quite a bit of this small instance's disk) before log rotation really kicks in. On this box, with 7 Juju units (including subordinates) plus the machine log, logs could easily take over 25% of the whole disk if no mitigation is put in place.
It'd be nice if log rotation could be customized in cases like this. Or perhaps it could be optionally addressed by logrotated on Ubuntu-based Juju units.
It seems reasonable that the max log file size and number of files be configurable. Juju uses the upstream lumberjack library to do the rotation and the file size and count are both hard coded. It is easy to make these controller config options.