公司刚上线的新系统，运维小李就被安全团队找上门——日志只存了30天，不符合内部审计要求。原来财务系统的操作日志按规定得保留180天，他按默认配置来，结果出了问题。
别小看这个数字，存储时间直接关系到事后追责
比如销售后台被人删了订单记录，查不到操作痕迹，就得靠日志还原过程。如果存得太短，等发现问题时日志早就被覆盖了，等于没留证据。
常见的系统像Linux服务器、防火墙、数据库，出厂设置大多是7到30天自动清理。但实际用的时候，得看你所在行业的规矩。金融类系统通常要求6个月以上，医疗相关可能要2年，而普通企业内部应用，90天算是个比较稳妥的底线。
配置前先搞清楚这三件事
第一，有没有行业合规要求？比如等保2.0里明确提到，三级系统日志应保存180天以上。第二，业务关键程度如何？核心交易系统肯定比测试环境要求高。第三，硬盘成本能不能承受？存一年的日志和存一个月，空间差好几倍。
拿Nginx访问日志举例，默认每天生成一个文件，不清的话磁盘迟早爆。可以用logrotate做切割归档：
/var/log/nginx/*.log {
daily
rotate 180
compress
missingok
notifempty
}这里的rotate 180表示最多保留180份旧日志，也就是半年左右。如果是阿里云RDS，可以直接在控制台开启“长期归档”，把日志转储到OSS上，成本低还省心。
有些公司喜欢全量保留原始日志，其实没必要。非核心系统的调试信息，存一个月足够排查问题了。重点是把登录行为、权限变更、数据删除这类高风险操作单独拎出来，延长保存周期。
技术上实现也不难，比如用ELK（Elasticsearch+Logstash+Kibana）架构，给不同类型的日志打标签，再通过索引生命周期策略（ILM）自动分层存储。关键日志放SSD，冷数据迁移到便宜的HDD或对象存储。
真正出事的时候，能快速调出来才是硬道理。光堆时间没用，还得配合清晰的命名规则和检索方式。建议每个月初检查一次日志策略，对照当前业务变化做调整，别让配置落后于实际需求。