日志压缩：别让服务器硬盘被日志吃光

上周帮朋友查一台卡顿的Web服务器，df -h 一看，/var/log 目录占了92%的磁盘空间。进去翻了翻，nginx-access.log.20240315.gz 居然有1.2G，而没压缩的 .log 文件堆了七八个，最大的一个快3G——这哪是日志，这是硬盘杀手。

日志不压缩，迟早出事

很多运维习惯把 logrotate 配好就不管了，但默认配置里 compress 往往是注释掉的，或者用的是 gzip 但没配 delaycompress，结果旧日志解压又重压，白白占空间。更常见的是，程序自己写的日志（比如 Python 的 logging 模块）压根没启用轮转，一天一个 gigabyte，一个月下来，/var/log 就成雷区。

几招实测有效的压缩方案

先看 logrotate 的关键配置段（以 nginx 为例）：

/var/log/nginx/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 0644 www-data www-data
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 `cat /var/run/nginx.pid`
        fi
    endscript
}

注意这两行：compress 表示每次轮转后自动 gzip 压缩；delaycompress 是重点——它让最新一轮的日志先不压，等下一轮再压，避免正在写入的日志被锁死或丢失。

如果想换更快的压缩算法（比如 zstd，比 gzip 省30%空间、快2倍），可以加一行：
compresscmd /usr/bin/zstd
uncompresscmd /usr/bin/unzstd
compressext .zst

手头没 logrotate？临时救急也简单

比如发现 /var/log/syslog 已经涨到 8G，立刻压缩：

gzip /var/log/syslog
# 会生成 syslog.gz，原文件自动删掉
# 如果不想删原文件，加 -c 参数：
gzip -c /var/log/syslog > /var/log/syslog.gz

批量压缩老日志（只压 .log 结尾、未压缩过的）：

find /var/log -name "*.log" -size +100M -not -name "*.gz" -exec gzip {} \;

压缩完记得检查：用 zcat /var/log/syslog.gz | head -20 看前20行是否正常，别压坏了。

小提醒：别为了省空间乱删

有人一着急直接 rm -rf /var/log/*，结果第二天 ssh 登不上——因为 auth.log 被删，fail2ban 找不到登录失败记录，安全策略全失效。还有 audit.log、kern.log 这些系统级日志，删了可能影响故障排查。宁可多压几次，别硬删。

日志压缩不是技术炫技，是每天该顺手点一下的事。就像关水龙头、拔充电器一样，小动作，防大坑。