日志合规概述：为什么需要日志保留与压缩？
干运维这些年，我见过太多团队把日志当“边角料”——生成了就扔那儿，磁盘满了就删，出了事才满世界翻。说实话，这种搞法迟早要翻车。日志保留和压缩，不是为了给运维找活干，而是你系统合规的“最后一道保险”。
合规法规在逼着你做日志保留
先聊最硬的逻辑：合规。你想想看，只要公司业务涉及用户数据、财务流水或者医疗信息，就逃不开各种法规的约束。这几年国内外的监管越来越严，罚款可不是闹着玩的。
| 法规/标准 | 适用场景 | 日志保留要求 | 典型处罚 |
|---|---|---|---|
| GDPR（欧盟） | 处理欧盟用户数据 | 保留至数据使用目的达成后删除，通常建议6个月~2年 | 最高2000万欧元或年营收4% |
| SOX（美国） | 上市公司财务系统 | 审计日志保留≥7年 | 高管刑事责任+巨额罚款 |
| PCI-DSS | 支付卡数据处理 | 日志保留≥1年，至少保留3个月在线可查 | 停止收单资格+每月罚款 |
| 等保2.0（中国） | 关键信息基础设施 | 日志留存≥6个月，部分系统≥1年 | 责令整改+警告 |
| HIPAA（美国） | 医疗健康信息 | 审计日志保留≥6年 | 最高150万美元/年 |
我接过一个项目，客户的财务系统被审计查出日志只存了3个月。SOX要求至少7年，最后补了半年数据才勉强过关。嗯，从那以后我把日志保留策略写进了项目上线 checklist 的第一项。
审计与取证：出事时日志就是你的命根子
合规不只是为了应付检查。举个例子，线上出了安全事件——数据泄露、误操作、恶意攻击，你用什么还原现场？说白了，日志就是唯一可靠的“黑匣子”。
- 谁在什么时间做了什么操作？看日志。
- 攻击者从哪个 IP 进来的？看日志。
- 数据库被 drop 了，是故障还是人为？还是看日志。
我个人习惯把访问日志、操作审计日志、错误日志各留一份副本，异地归档。原因很简单——生产服务器被扛走了，你还能从归档里捞到完整记录。我在一家金融公司见到过这样的案例：服务器磁盘全部被加密勒索，但日志存在冷存储里，最终靠日志搞清楚了勒索入口。
成本与性能：不压缩的话你根本存不起
你是不是觉得“保留日志”就是找个文件夹放那儿？错了。想想一天产生多少行 —— 一个小型微服务集群，一天能吐出几十GB。一个月就是TB级。不搞压缩，你硬扛试试？
存储成本只是一方面。日志还拖慢系统性能：文件系统 inode 用光、磁盘 IO 被打满、日志收集工具满负荷。我曾经遇到一个 case：日志没做滚动压缩，单机日志文件涨到 400GB，结果 `logrotate` 都跑不动了，磁盘直接 100% 占用，生产服务挂了。血的教训。
gzip，压缩比大概 5:1 到 10:1；如果对速度有要求，试试 zstd，性能和压缩比都更均衡。
来看一下常见压缩算法的对比：
| 算法 | 压缩比（近似） | 压缩速度 | 解压速度 | 适用场景 |
|---|---|---|---|---|
| gzip | 5:1 ~ 8:1 | 中等 | 中等 | 通用日志压缩，兼容性最好 |
| zstd | 6:1 ~ 12:1 | 快 | 快 | 高吞吐日志系统，比如 Kafka 日志 |
| lz4 | 2:1 ~ 4:1 | 极快 | 极快 | 实时日志传输，对延迟敏感的场景 |
| bzip2 | 8:1 ~ 15:1 | 慢 | 慢 | 归档类日志，不常读的冷存储 |
日志保留与压缩的整体思路
把上面这些串起来，你就清楚为什么要同时做保留和压缩了：
- 合规要求：强制你存够规定年限，不得随意删除。
- 审计与溯源：需要日志可查询、可回溯。
- 存储成本：压缩是控制成本的唯一手段。
- 系统性能：不压缩和滚动，日志会拖垮磁盘和 CPU。
下面这张图可以帮你理清它们之间的关系：
避坑指南：我踩过的几个深坑
讲点实际教训，这些都是我用真金白银换来的经验。
md5sum 校验文件，定期巡检。
lz4 和 gzip。
grep 一次要几分钟。后来我用 logrotate + compress 选项，每天切分，保留 90 天。
总结：这件事不做不行
日志合规保留与压缩，不是锦上添花。它是你系统可靠性、安全性、合规性的根基。法规检查、安全事故、成本审计，哪一个都绕不开它。后面的章节我们会一步步拆解如何落地——从保留策略设计、压缩算法选型，到自动化脚本与监控。但这一章你要记住一句话：日志存不好，出事跑不了。
趁着现在还没出问题，早点把策略定下来。