Linux日志管理实战：rsyslog与journald大小限制配置指南（Ubuntu/Debian）

在新开的Linux系统中（以Ubuntu和debian为例）我们应当尽量保持日志文件的有效更新以及日志文件大小的限制，否则若有恶意请求进行爆破或者其他大量请求需要记录容易造成本地存储爆满所以我们需要合理运用日志文件的配置。

由于我是个人站点使用，没有什么合规要求，如果有合规要求也可以作为参考进行参数调整。

本文分为两点，一从rsyslog调整日志大小（通过logrotate），二是限制journald（systemd日志）大小。

一、限制rsyslog日志大小

由于rsyslog本身不能直接通过自身来控制自身文件的大小，我们需要通过logrotate来进行配置调整

在ubuntu/debian系统中一般有自带rsyslog，可以用以下命令来查看rsyslog生成的命令

grep -r "/var/log/.*log" /etc/rsyslog*

并且系统Ubuntu/Debian默认已安装logrotate并为 rsyslog 提供了/etc/logrotate.d/rsyslog配置。

修改配置文件

我们打开它进行修改sudo nano /etc/logrotate.d/rsyslog内容大致如下（主要是大括号内的内容）：

/var/log/syslog
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
	rotate 3
	weekly
	maxsize 50M
	missingok
	notifempty
	compress
	delaycompress
	sharedscripts
	postrotate
		/usr/lib/rsyslog/rsyslog-rotate
	endscript
}

参数概要

参数	说明	功能描述
rotate 3	保留副本数	保留3个旧的日志文件副本（如：log.1, log.2, log.3）
weekly	轮转周期	每周执行一次日志轮转
maxsize 50M	大小触发	日志文件超过50MB时立即轮转（不受周期限制）
missingok	容错处理	如果日志文件不存在，不报错，继续处理下一个
notifempty	空文件处理	如果日志文件为空，则不进行轮转
compress	压缩设置	轮转后的旧日志文件使用gzip压缩
delaycompress	延迟压缩	最近一次的轮转文件不压缩，下次轮转时再压缩
sharedscripts	脚本执行	所有匹配文件轮转后只执行一次postrotate脚本
postrotate…endscript	后处理脚本	轮转后执行指定命令（通知rsyslog重新打开日志文件）

若机器有在涉及审计、安全合规（如等保、GDPR、ISO 27001、PCI DSS、SOX等）的场景中，若您的磁盘较小需要及时将您的日志实时发送到外部日志服务器或云日志服务或使用单独的专用日志分区。

调整建议

可以根据服务器的存储空间大小来弹性调整maxsize，并且可以适当多保存一些旧的副本数。

此外还需注意大小触发和轮转周期的冲突性，触发逻辑是 “满足其一即轮转”。以下是原理上潜在问题的后果：

---

日志增长情况（当日志少的时候）

• 周一：/var/log/syslog = 10MB
• 周二：20MB
• …
• 周日：40MB（仍 < 50MB）

结果：
在周日夜间（logrotate通过cron执行时），因为满7天，触发轮转。
→ 生成syslog.1，当前syslog清空。

---

日志增长情况（当日志多的时候）

• 周三上午：日志 = 10MB
• 周三下午：系统遭 SSH 暴力破解，日志暴增至 120MB

结果：
在周三夜间（logrotate 每天运行一次），发现日志 >50MB → 立即轮转，不等周日！
→ 生成 syslog.1，当前文件清空。

---

可以看出，当maxsize 50M或者时间weekly条件只要有一条符合就能够出发轮转。

合规需要注意

当maxsize 50M或者时间weekly条件只要有一条符合就能够出发轮转。

当maxsize 50M或者时间weekly条件只要有一条符合就能够出发轮转。

当maxsize 50M或者时间weekly条件只要有一条符合就能够出发轮转。

⚠️注意：若有合规要求且保留副本数量（rotate）不够多，无法满足法定/合规保留期限

⚠️注意：若有合规要求且保留副本数量（rotate）不够多，无法满足法定/合规保留期限

⚠️注意：若有合规要求且保留副本数量（rotate）不够多，无法满足法定/合规保留期限

若机器有在涉及审计、安全合规（如等保、GDPR、ISO 27001、PCI DSS、SOX等）的场景中，若您的磁盘较小需要及时将您的日志实时发送到外部日志服务器或云日志服务或使用单独的专用日志分区。

二、限制 journald（systemd 日志）大小

systemd 的 journal 日志默认存储在 /var/log/journal/（若启用持久化）或内存中（默认只内存）。若你启用了持久化（即 /var/log/journal 存在），它可能无限制增长。

检查当前journal配置

sudo systemctl is-active systemd-journald
ls /var/log/journal  # 若存在，说明启用了持久化
journalctl --disk-usage

编辑 journald 配置：

sudo nano /etc/systemd/journald.conf

内容可以如下

[Journal]
# 存储到磁盘，重启后可查历史日志（服务器刚需）
Storage=persistent

# 总磁盘日志上限设为 500M —— 根据自己存储时间来指定
SystemMaxUse=400M

# 单个日志文件最大 50M，避免单文件过大影响读写性能
SystemMaxFileSize=50M

# 内存中最多缓存 80MB 活跃日志（快速访问最近内容）
RuntimeMaxUse=80M

# 留 40 天！
MaxRetentionSec=40days

# 每5天轮转一个日志文件（减少碎片，便于管理）
MaxFileSec=5day

# 压缩日志（节省空间，几乎不影响 CPU）
Compress=yes

# 关闭无用转发（降低干扰和资源消耗）
ForwardToSyslog=no
ForwardToWall=no
ForwardToKMsg=no

# 延长磁盘同步间隔，降低 IO 压力（适合超开云盘）
SyncIntervalSec=2min

# 防止单个服务/容器疯狂打日志冲垮系统
RateLimitIntervalSec=30s
RateLimitBurst=20000

如果你在不到 40 天的时间内就达到了SystemMaxUse=400M的磁盘空间上限，journald会自动删除最旧的日志，以确保总占用不超过400MB—— 即使还没到MaxRetentionSec=40days的保留期限。

⚠️注意：若有合规要求且保留文件大小不够大（SystemMaxUse），无法满足法定/合规保留期限

⚠️注意：若有合规要求且保留文件大小不够大（SystemMaxUse），无法满足法定/合规保留期限

⚠️注意：若有合规要求且保留文件大小不够大（SystemMaxUse），无法满足法定/合规保留期限

如何验证当前实际保留了多久？

# 查看 journal 实际磁盘占用
journalctl --disk-usage

# 尝试查看最早一条日志的时间
sudo journalctl --since "2025-01-01" | head -n1
# 或直接看第一条
sudo journalctl | head -n1

如果第一条日志的时间是5天前，说明虽然你设了40天，但实际由于文件过大只保留了5天。