别让运维日志堆成硬盘杀手高效清理加实用风险规避

先唠唠为什么这事儿不能等

你有没有发现，平时敲代码看监控忙得脚不沾地，根本没空想角落的日志？直到某天监控弹窗炸锅，提示“磁盘空间不足8%，服务随时可能挂”，才慌慌张张去删，删的手还抖——万一删了有用的排查记录咋办？

上周我徒弟就踩了这个坑，测试环境删日志顺手清了生产核心的半份Nginx访问日志，刚好赶上当天有个用户投诉支付超时，找溯源记录找了大半天，差点扣绩效。

说白了，运维日志就像家里的快递盒，每天拆每天攒，不及时整理分类，要么占地方卡“生活节奏”，要么乱塞一通关键时刻找不到保修卡说明书。

第一步不是删！是定好「生死线」

直接删是新手干的傻事，老运维第一步都是给日志标上“保质期”。

先搞清楚哪些日志不能碰，碰了要背锅

不是所有日志都叫可以删的垃圾，有些是合规要求必须留的，比如金融类的支付交易日志、监管部门要求的系统审计日志，一般得存3个月到1年不等，具体看你们公司的合规手册，别自己瞎改。

还有排查类的临时重要日志，比如上周刚出的那个支付超时，当时导出备份的那部分得单独存一块小空间，等问题彻底复盘归档半年再考虑删。

剩下的普通日志，按「重要程度+周期」分层

• 核心应用的ERROR级日志：可以存久一点，比如30天，万一出现间歇性问题能翻
• 核心应用的INFO/WARN级日志：INFO存7天够看流量波动，WARN存14天提前预警潜在问题
• 测试/预发布环境的全量日志：这玩意儿最占地方！存3天顶天了，除非测试同事有特殊需求，提前打招呼单独留
• 系统本身的日常轮转备份外的冗余日志：比如有些老版本的日志轮转工具，会留下重复压缩包，直接删就行

第二步用工具自动化，别每天手动删到吐

定好规则之后，谁还愿意天天去敲rm命令啊？万一敲错路径敲成/，整个公司服务器都没了。

Linux环境最常用的就是logrotate

这个工具是系统自带的，不用额外装，老稳定了。简单改个配置文件就行，我给你们放个核心应用的配置模板，照着套基本没问题：

``` 假设是核心支付服务的日志路径 /var/log/pay-service/.log { daily 每天轮转一次 rotate 30 ERROR级存30天？不对刚才分层了，这里可以给不同级别单独写配置，举个INFO的例子 rotate 7 INFO级存7天 compress 轮转后的日志自动用gzip压缩，省一半多空间 delaycompress 今天刚轮转的那份不压缩，方便紧急排查用 missingok 日志文件不存在的话，别报错，继续运行 notifempty 日志文件是空的，就不轮转 create 0640 root root 新生成的日志文件权限设为0640，只有root和同组能看，安全 sharedscripts 所有日志轮转完再执行下面的脚本 postrotate 轮转后重启应用的日志服务，不然应用还会往旧文件写 systemctl reload pay-service endscript } ```

对了，把配置文件放在/etc/logrotate.d/目录下，系统默认每天凌晨3点左右会自动执行logrotate的任务，想改时间的话可以去/etc/crontab或者/etc/anacrontab里调，别改在业务高峰期就行。

嫌logrotate麻烦？可以用Docker自带的日志驱动

如果你们是用Docker部署的应用，更简单了，直接在docker-compose.yml或者启动命令里加日志配置，比如：

``` services: pay-service: image: your-pay-service-image logging: driver: json-file Docker默认的json日志驱动，也可以换成别的 options: max-size: "10m" 单个日志文件最大10M max-file: "7" 最多存7个轮转后的文件，也就是最多70M ```

这样Docker会自动帮你处理日志，不用再单独装工具写配置，太香了。

最后再提两个小细节，规避风险

第一个细节，删除压缩包的时候，先用ls -lh看一下大小和修改时间，别删错了，实在不放心可以先用mv命令移到一个临时回收站目录，放24小时没问题再删。

第二个细节，定期做磁盘空间监控，别等弹窗炸锅才发现，用Prometheus+Grafana或者Zabbix都可以，设置一个80%的预警阈值，提前处理。

好了，今天的分享就到这儿，赶紧回去看看你们的服务器日志堆成啥样了吧！