Log volume budget — planning disk, network and observability capacity for logs

Logs are the firewall operator’s evidence trail and the security team’s primary signal. Every connection that crosses the firewall can generate a log entry; every IDS rule that fires generates an alert; every authentication attempt generates an event. The volume adds up. A busy firewall with verbose logging can produce gigabytes of log data per day; a deployment that does not budget for log volume finds its disk full, its syslog forwarding broken, and its alerts silent — exactly when the operator needs the logs the most.

This lesson covers the log volume budget — the sources of log volume, the bytes per event for each, the disk capacity needed for local retention, the network bandwidth needed to forward logs to a central observability stack, and the discipline of monitoring log volume before the disk fills.

The sources of log volume

The OPNsense firewall produces logs from:

• Firewall log. Every connection that matches a rule with logging enabled produces one entry per packet that hits the rule. Default behaviour: rules log the first packet of each flow; some configurations log every packet.
• System log. OPNsense daemon events — DHCP leases, DNS queries, VPN events, HA state changes, configuration changes.
• IDS log. Every Suricata alert produces one entry. With a busy ruleset on a busy network, IDS log volume can dwarf firewall log volume.
• VPN log. IPsec and WireGuard events — connection state, authentication, rekey.
• DNS log. Every DNS query, every response — depending on the configuration.
• Web proxy log. Every HTTP/HTTPS request, if TLS interception is enabled.

The dominant sources depend on the configuration. A deployment with verbose firewall logging on a busy network has the firewall log as the dominant source. A deployment with Suricata in IDS mode with a large ruleset has the IDS log as the dominant source.

Bytes per event

The bytes per log event vary by source:

The firewall log is per-flow by default (the first packet of each flow is logged). At 10,000 flows per minute with 250 bytes per event, the firewall log produces 2.5 MB per minute, 150 MB per hour, 3.6 GB per day.

The IDS log is per-alert. A busy deployment with 1 alert per second produces 500 bytes × 86,400 = 43 MB per day. A noisy deployment with 100 alerts per second produces 4.3 GB per day — and that is just the IDS log.

Sizing disk capacity

The disk capacity calculation:

disk_capacity = daily_log_volume × retention_days × growth_factor

For a deployment with:

• 5 GB per day (firewall + system + VPN + DNS)
• 30 days retention
• 1.5x growth factor (account for spikes and trends)

disk_capacity = 5 GB × 30 × 1.5 = 225 GB

A 256 GB SSD dedicated to logs is sufficient; a 128 GB SSD is too small. The discipline: dedicate a disk partition to logs (separate from the OS), size for the retention period with growth factor, monitor the usage trend.

# Check log directory usage.
du -sh /var/log/

# Check disk usage.
df -h /var/log/

# Check log file count and sizes.
ls -la /var/log/

Sizing network bandwidth for log forwarding

The network bandwidth calculation:

log_bandwidth = log_volume_per_second × log_message_size × replication_factor

For a deployment with:

• 5 GB per day
• Forwarding to two observability stacks (local archive + cloud archive)

log_bandwidth = (5 GB / 86400) × 2 = 116 KB/s

A 116 KB/s log stream is negligible on a 1 Gbps network. A 10 MB/s log stream (from a busy deployment with verbose logging) is still small relative to a 1 Gbps link, but it is significant on a 100 Mbps WAN link.

The discipline: account for log forwarding in the WAN bandwidth budget. A deployment that forwards 10 MB/s of logs to a cloud observability stack uses 10% of a 100 Mbps link just for logs.

# Check syslog forwarding rate.
iftop -i igb1 -f 'port 514'

Log forwarding and back-pressure

The log forwarding pipeline has back-pressure characteristics:

• Local syslog. OPNsense’s syslog daemon writes to local files. When the disk is full, syslog drops messages. The drops are silent — the operator sees gaps in the log but no error.
• Remote syslog. OPNsense forwards logs to a remote syslog server (over UDP or TCP). UDP is fire-and-forget — drops are silent. TCP has back-pressure — when the remote is slow, the local queue grows.
• TLS-encrypted syslog. TCP with TLS encryption adds CPU cost but provides confidentiality. The encryption cost is small per message but can dominate on a busy deployment.

The discipline:

• Use TCP for remote forwarding. UDP drops silently; TCP has back-pressure. The operator sees when the remote is slow.
• Monitor the local queue. netstat -an | grep 514 shows the connection state; a persistent ESTABLISHED state with no flow is a queue backup.
• Alert on log forwarding delays. A forwarding delay of more than 60 seconds is a problem; the operator investigates.

Log retention policies

The retention policy is part of the log volume budget. The discipline:

• Define retention by data type. Firewall logs (operational): 30-90 days. IDS alerts (security): 90-365 days. Authentication events (compliance): 1-7 years per the compliance regime.
• Use log rotation. OPNsense rotates logs daily by default. The rotation compresses old logs and deletes the oldest when the retention is reached.
• Forward to long-term storage. Local retention is short-term; long-term retention is on the observability stack (Loki, Elasticsearch, S3).
• Test the retention policy. The operator must verify the policy works — that old logs are deleted, that the disk does not fill, that the forwards are working.

# Check log rotation configuration.
cat /etc/newsyslog.conf

# Check the rotation is happening.
ls -la /var/log/ | head -20

Symptoms of log volume saturation

The signatures of a firewall that is log-volume-saturated:

• Disk usage rising. df -h /var/ shows the disk filling. The trend is more informative than the absolute value.
• Log rotation failures. newsyslog fails to rotate because the disk is full; old logs accumulate; eventually syslog cannot write new entries.
• Syslog forwarding delays. The TCP forwarding queue grows; the operator sees delays in the logs arriving at the remote.
• Service failures. When /var/ fills completely, services that need to write state files fail. DHCP stops renewing leases; Unbound cache writes fail; Suricata cannot write stats.
• Silent log gaps. The local log has gaps where messages were dropped; the operator sees the gaps in the log file.

The discipline: monitor disk usage and log volume as canary metrics; alert at 80% disk usage; investigate immediately.

Verification

After deploying the log volume budget, verify:

1. df -h /var/ shows usage below 80% — headroom remains.
2. Log rotation is happening daily — old logs are compressed and deleted.
3. Log forwarding to remote is working — the remote observability stack has the logs.
4. Log volume matches the budget — within 20% of the predicted volume.
5. No log gaps in the local or remote logs — syslog is not dropping messages.

A log volume budget that meets 1-2 but fails 3-5 has disk capacity but loses messages. The operator investigates the forwarding pipeline.