Actually I not know nothing about log rotation before last month XD my disk full every week and I think 'not my circus, not my monkeys' but it IS my monkeys because server down
Learned logrotate proper now. Not hard actually. Just nobody tell you
Actually I not know nothing about log rotation before last month XD my disk full every week and I think 'not my circus, not my monkeys' but it IS my monkeys because server down
Learned logrotate proper now. Not hard actually. Just nobody tell you
Disk full at 3am again. 47gb nginx access log. No rotation. Ticket open since 4 days. No response.
Found logrotate.conf. 15 minutes. Problem gone. Should have done in 2019.
My clients expect premium service so I can't afford disk issues. I have support ticket system for this. Our premium log management handled by premium team.
Actually for my own box I just use journald. Clients get premium though.
Systemd-journald with Storage=persistent and SystemMaxUse=500M works well for small vps. I run this on HostHatch Tokyo and GreenCloudVPS Tokyo.
No need install extra tools if you already on systemd.
IMO logrotate is fine but YMMV depending on your distro defaults. Debian and Ubuntu ship reasonable configs. CentOS ones tend to be more aggressive with rotation frequency.
Take it with a grain of salt: check what your package manager actually installed. Some images from cheap providers strip logrotate entirely to save 2mb image size.
Fun little project: my 'log rotation' was cron job for 2 years
0 4 * * * root find /var/log -name "*.log.*" -mtime +7 -exec rm -f {} \;It actually works. Hasn't failed yet. (I know. I know. I am moving to logrotate this weekend. Probably.)