Calculate storage required for centralized syslog collection from a fleet of hosts.
Syslog volume scales directly with message rate and average message size (syslog_per_day = messages_per_sec × avg_size_bytes × 86400), but rsyslog/syslog-ng facility and priority filtering rules (e.g. dropping debug-level or noisy facility.* messages before they're written to disk) can dramatically cut what's actually stored versus what's generated. Filtering decisions in /etc/rsyslog.d/ (like `*.debug /dev/null` or facility-specific routing to separate lower-retention files) trade log completeness for storage — filtered-out messages are gone rather than merely rotated away later.
Daily syslog volume
syslog_per_day = messages_per_sec × avg_message_size × 86400 × (1 − filtered_fraction)
Rules like `mail.*,news.none /var/log/other.log` or `*.debug /dev/null` in rsyslog.conf/rsyslog.d selectively route or discard messages by facility (source subsystem, e.g. mail, cron, auth) and priority (severity, e.g. debug through emerg) before they're ever written to a log file, so filtered messages consume no disk space at all rather than just being rotated away sooner.
Filtering trades storage savings for forensic completeness — if an incident later requires reconstructing exactly what happened, filtered-out lower-severity messages are permanently unavailable (unlike rotated logs, which are just delayed deletion), so filtering rules should be reviewed against compliance and incident-response requirements, not set purely for storage convenience.
`journalctl --since "1 minute ago" | wc -l` gives a rough recent rate for systemd-journald; for rsyslog specifically, enabling `impstats` module reports message throughput statistics directly, which is more accurate than inferring from log file growth alone.