Skip to content
Calcrivo

Syslog Storage Calculator

Estimate daily syslog volume from message rate and average size, with facility/priority filtering impact.

Inputs

Stored Syslog Volume per Day

177.98 MB

Total Storage for Retention Period

5.21 GB

Raw (Unfiltered) Volume per Day

296.63 MB

Storage Saved by Filtering (over retention)

3.48 GB

Step by step

  1. Values used

    Syslog Messages per Second = 20; Average Message Size (bytes) = 180; Fraction Filtered Out by Facility/Priority Rules (%) = 40; Retention Period (days) = 30

  2. Daily syslog volume

    syslog_per_day = messages_per_sec × avg_message_size × 86400 × (1 − filtered_fraction)

  3. Stored Syslog Volume per Day

    = 177.98 MB

  4. Total Storage for Retention Period

    = 5.21 GB

  5. Raw (Unfiltered) Volume per Day

    = 296.63 MB

  6. Storage Saved by Filtering (over retention)

    = 3.48 GB

How it works

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.

Formula

Daily syslog volume

syslog_per_day = messages_per_sec × avg_message_size × 86400 × (1 − filtered_fraction)

m
messages per second
s
average message size
f
fraction filtered out

Frequently Asked Questions

How do rsyslog facility and priority filters actually reduce storage?

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.

What's the risk of filtering out debug or info-level syslog messages?

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.

How do I measure actual syslog message rate on a live system?

`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.

You might also need

Related Calculators

Log Rotation Size CalculatorAudit Log Growth CalculatorKernel Log Size Calculator