CN
EN
在Debian服务器运维中，/var/log/syslog 是最容易被忽视的磁盘消耗源。一个持续运行数月的Web服务器，syslog文件突破GB级别并不罕见；如果没有合理的轮转与压缩策略，磁盘写满导致服务中断只是时间问题。Debian的日志管理并非“配置一次就完事”——它涉及rsyslog、systemd-journald和logrotate三套机制的协同运作。本文从日志体系梳理出发，逐步拆解压缩配置、性能权衡与验证方法。
Debian日志体系：先搞清谁在写、谁在管
Debian的日志管理存在两套并行系统，理解它们的分工是配置压缩的前提。
rsyslog负责将内核与应用程序日志写入 /var/log/ 下的文本文件，包括 syslog、auth.log、kern.log 等。这些文件是本文压缩策略的主要对象。systemd-journald则维护一套二进制结构化日志，存储在 /var/log/journal/ 或 /run/log/journal/ 中，通过 journalctl 查询。
logrotate 是管理文本日志轮转与压缩的独立工具，通常由 /etc/cron.daily/logrotate 每日触发。journald 的压缩则通过其自身的 Compress 选项控制，走的是与 logrotate 完全不同的路径。
两者的关系是：journald 可选地通过 imjournal 模块将日志转发给 rsyslog，rsyslog 再写入文本文件。这意味着同一份日志可能同时占用两份磁盘空间——如果对容量敏感，可以在 /etc/systemd/journald.conf 中设置 ForwardToSyslog=no 来关闭重复写入。
logrotate压缩配置：从基础到精调
Debian默认的rsyslog轮转配置位于 /etc/logrotate.d/rsyslog，但许多安装场景下并未启用压缩。一个完整的压缩配置如下：
/var/log/syslog
{
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 0640 root adm
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}核心参数的含义值得逐一说明。compress 启用gzip压缩，典型场景下可节省50%至70%的磁盘空间。delaycompress 将压缩推迟到下一次轮转时执行，只保留最近一份未压缩的归档文件——这对故障排查至关重要，因为当天的归档仍然可以直接用 tail 或 grep 查看，不必先解压。rotate 7 限定保留7份归档，结合压缩后的体积，通常能将 syslog 的磁盘占用控制在数十MB以内。
如果需要对压缩级别做精细控制，logrotate 支持通过 compressoptions 传递参数。gzip 的默认压缩级别为 -6，在压缩率与CPU开销之间取得了平衡；设置 -9 可获得更小的文件体积，但压缩时间会显著增加。
compress
compressoptions -9对于写入频率极高的日志（如高流量Nginx访问日志），可考虑将轮转频率从 daily 提升至 hourly，配合 maxsize 参数实现按容量触发：
/var/log/nginx/*.log
{
hourly
maxsize 100M
rotate 48
compress
delaycompress
postrotate
/usr/sbin/nginx -s reopen
endscript
}systemd-journald的压缩机制
journald 的压缩策略与 logrotate 完全不同。它默认启用 Compress=yes，对大于512字节的数据对象使用XZ算法在写入前完成压缩。这意味着journald的日志从诞生之初就是压缩存储的，无需额外的轮转配置。
真正需要手动干预的是容量控制。在 /etc/systemd/journald.conf 中设置以下参数：
ini
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=1G
MaxRetentionSec=30day
Compress=yesSystemMaxUse 限制journal日志的磁盘占用上限，超出后自动删除最旧的归档文件；MaxRetentionSec 设定时间维度的保留上限。两者同时生效时，以先触发的条件为准。修改后执行 sudo systemctl restart systemd-journald 生效。
性能权衡：压缩不是免费的
日志压缩的收益是磁盘空间，代价是CPU周期与I/O操作。压缩过程需要读取原始日志、执行压缩算法、写回压缩文件，这三个步骤都会产生额外的磁盘读写和CPU负载。对于磁盘I/O本身已是瓶颈的服务器，频繁的日志压缩可能加剧系统负载。
务实的策略是按日志价值分级压缩。系统日志（syslog、kern.log）保留7天并启用压缩即可；安全审计日志（auth.log）建议保留30天以上且优先考虑远程集中存储而非本地压缩；高吞吐的服务日志（Nginx、应用日志）如果写入量极大，可将 rotate 值降低至3至4份，用更短的保留期换取更少的压缩操作。对于日志量极大的场景，可以将 logrotate 的压缩命令从 gzip 替换为 zstd，后者在相近压缩率下速度更快，但需要确认系统已安装 zstd。
配置验证与故障排查
配置完成后，用以下步骤验证效果。首先强制触发一次轮转，确认压缩文件正常生成：
sudo logrotate -f /etc/logrotate.d/rsyslog
ls -lh /var/log/syslog*输出中应看到 syslog（当前文件）、syslog.1（延迟压缩的上一份归档）以及 syslog.2.gz 等压缩归档。如果压缩文件未生成，检查是否遗漏了 compress 指令，或确认 logrotate 的 cron 任务是否存在。
另一个常见问题是轮转后 rsyslog 继续写入已归档的文件，导致 .gz 文件被污染。这需要在 logrotate 配置中添加 postrotate 脚本通知 rsyslog 重新打开文件句柄。Debian下通常使用 /usr/lib/rsyslog/rsyslog-rotate 或 invoke-rc.d rsyslog rotate > /dev/null。
Debian日志压缩的核心逻辑可以概括为：logrotate管文本日志的轮转与压缩，journald管二进制日志的内置压缩，两者各司其职但需避免重复存储。配置的关键不在于启用 compress，而在于根据日志类型和磁盘预算设定合理的保留份数与压缩级别，并在压缩收益与CPU开销之间找到适合自己的平衡点。
