4. 日志存储与管理：日志轮转、日志压缩、日志归档策略

日志存着存着，磁盘就爆了。这事儿我碰过不止一次。

最惨的一次，FTP的vsftpd日志直接把根分区写满了。业务停了半小时，老板拍桌子，我背锅。从那以后，我养成了一个习惯——不管项目多急，先把日志轮转配好，再谈别的。

这一章，说白了就是告诉你：日志不能只写不删，也不能只删不存。轮转、压缩、归档，三个动作必须串成一条策略线。

4.1 日志轮转：什么时候该切，切多块

日志轮转是按时间或大小把当前日志文件“切”成新文件，旧文件保留或删除。别等着你自己手动去删，那太原始了。

我个人习惯用 logrotate，Linux 上标配。配置文件在 /etc/logrotate.conf，每个服务的规则放在 /etc/logrotate.d/ 下。

实战中我是这么配 FTP 日志轮转的：

/var/log/vsftpd.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root utmp
    postrotate
        /usr/bin/killall -HUP vsftpd 2>/dev/null || true
    endscript
}

简单解释几个关键参数：

• daily：每天轮转一次。你也可以设 weekly 或 size 100M。
• rotate 7：保留最近 7 份轮转后的日志。多了占地方，少了没回溯。
• compress：旧日志自动 gzip 压缩。
• delaycompress：压缩延迟一次。这招很实用——昨天切的日志今天才压，防止正在写的进程出问题。

4.2 日志压缩：存储空间是靠压出来的

轮转后的日志随便一个纯文本可能上百兆。不压缩，档案馆能让你塞爆。

我建议在 logrotate 里直接加 compress 选项，默认用 gzip，压缩率一般在 80% 以上。100MB 的原日志能压到 10MB 左右。

压缩工具	压缩率（典型）	CPU 开销	解压速度
gzip	70%~90%	低	快
bzip2	80%~95%	中	中等
xz	90%~98%	高	慢
zstd	75%~92%	低（可调）	极快

生产环境我推荐 gzip 或 zstd。zstd 可以调压缩等级，对 FTP 日志这种重复性高的文本效果很好。

4.3 日志归档：该搬走的就搬走

日志在磁盘上轮转保留一段时间后，就得往冷存储搬。这是归档。

我的经验是：线上磁盘保留 30 天轮转日志，超过 30 天的打包归档到 NAS 或对象存储（比如 S3、MinIO）。归档命名规则一定要统一，否则你找日志的时候会疯。

推荐一个归档文件名格式：

vsftpd-2025-04-01.log.gz
vsftpd-2025-04-02.log.gz

归档策略表（根据业务规模调整）：

存储层级	保留期限	内容	说明
热存储（SSD）	当前 + 最近 30 天	轮转后未压缩 / 已压缩	日常查询用，响应要快
温存储（HDD）	31~180 天	gzip 压缩归档	合规审计，偶尔翻查
冷存储（磁带/对象存储）	181 天以上	xz 或 gzip 压缩包	法律取证，极少访问

归档脚本的要点：一是要 atomic，要么全成功，要么不动原文件；二是要做校验，归档后比对 md5，防止数据损坏。

4.4 三种策略怎么搭配

我总结了一条经验流：

1. 轮转：每天按 size 或时间切一次，本机留 7~30 份。
2. 压缩：延迟压缩，轮转后隔天再压，保证进程不影响。
3. 归档：本机保存时间到了就 rsync/cp 到远程存储，然后清理本地。

4.5 避坑清单（我踩过的）

• 轮转后忘了发信号——日志一直写旧文件，新文件是空的。排查问题时什么都看不到。
• 压缩等级设太高——xz -9 压一个100MB日志用了5分钟，CPU直接100%。日常用gzip -6或zstd -3就够了。
• 归档没做 md5——有一次硬盘静默坏道，归档文件全是坏数据，还好本地副本没删。
• 权限没保持一致——logrotate用root创建的新日志，vsftpd进程写不了，日志直接断流。