rsyslog & logrotate

rsyslog

rsyslog is the traditional daemon responsible for actually routing log messages to the right files under /var/log. It sorts incoming messages by two properties: facility (a rough category - auth, cron, kern, mail, etc.) and priority (severity, the same scale you met with journalctl's -p flag). Its routing rules live in /etc/rsyslog.conf and /etc/rsyslog.d/.

auth,authpriv.*     /var/log/auth.log
*.emerg             :omusrmsg:*

That first line reads as "anything tagged with the auth or authpriv facility, at any priority (*), goes to /var/log/auth.log" - which is exactly how authentication events end up in that specific file rather than mixed in with everything else.

logrotate

Left unmanaged, log files grow forever and can eventually fill a disk entirely - a recurring, entirely preventable cause of "disk full" incidents. logrotate runs on a schedule (typically triggered by cron or a systemd timer) and compresses, archives, and eventually deletes old log files according to rules you define, so a service's logs never grow unbounded.

# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    weekly
    rotate 4
    compress
    missingok
    postrotate
        systemctl reload nginx
    endscript
}

The postrotate/endscript block matters more than it might look: many services keep a log file open by its original file handle, and simply renaming the file out from under them (which is what rotation does) doesn't make them start writing to the new one - they'd keep writing into the old, now-renamed file forever. Reloading the service (as shown here) tells it to reopen its log file at the expected path, picking up the fresh one rotation just created.

Tip: rotate 4 combined with weekly keeps four weeks of history before the oldest archive is finally deleted - a good default mental model for reading any logrotate config at a glance: multiply the rotation frequency by the rotate count to get total retention. Before trusting a new or edited logrotate config in production, logrotate -d <file> runs a dry run - it prints exactly what would happen without touching any actual files, letting you verify the rules before they run for real.