系统日志体积控制：journald 与 rsyslog 的轮转与保留

发布时间:2026-10-11 17:13

服务器跑久了，日志悄悄吃掉几十个 G 的情况很常见，等磁盘告警才想起来处理，往往已经被日志拖垮了别的服务。日志治理要在装完系统、业务上线前就配好，核心是两件事：限制 journal 的体积上限，给传统文本日志配好轮转。 ## 场景与判断 先用 journalctl --disk-usage 看 systemd 日志占了多少，再 du -sh /var/log 逐层看文本日志的分布，重点盯 /var/log/messages、secure 这类系统日志和各应用自己写的大文件。两类日志走两套机制：journald 是二进制日志，靠自身配置限制体积；rsyslog 写的文本日志靠 logrotate 轮转。 ## 步骤清单 journald 侧编辑 /etc/systemd/journald.conf，把 SystemMaxUse 设成一个明确上限，比如 500M，Storage 保持默认即可，改完执行 systemctl restart systemd-journald 生效。应急清理可以用 journalctl --vacuum-size=200M 直接把存量压到目标体积。 文本日志侧给 /etc/logrotate.d/ 下加一条规则：daily 按天轮转、rotate 14 保留两周、compress 归档压缩、missingok 与 notifempty 兜底。对不愿意重开文件句柄的应用，用 copytruncate 方式轮转，对支持重开句柄的服务，用 postrotate 里发信号的方式更安全。改完用 logrotate -d 规则文件先干跑验证语法，再强制触发一次确认文件确实切开了。 ## 验证与注意事项 验证看三点：journalctl --disk-usage 回落且后续稳定在上限附近；轮转产生的 .gz 归档正常出现；一周后 df 不再单向增长。注意两件事：不要直接 rm 正在被进程写入的日志文件，空间不会释放，句柄还握着，必须走轮转或重启服务；应用自己写的日志不在系统轮转覆盖范围内，要单独配规则，别只管好系统日志就认为完事。 多台机器的场景下，日志治理还有一个方向是把关键日志集中转发：rsyslog 配一条转发规则，把 secure 与认证类日志同步送到专用日志机，本机保留期就可以压短，日志机的磁盘单独扩容，排查跨机事件时也只需登一处。转发规则要配队列与重试，网络抖动时日志先落在本地缓冲，别因为日志机不可达把业务机的磁盘又堆满。保留期按排查需要定，两周到一个月是常见区间，有合规留痕要求的业务按要求数值走。