说到清理日志会不会影响服务，这个问题确实值得好好聊聊。我自己在运维工作中就遇到过不少类似的情况，有时候一个不小心，真的可能把服务搞挂掉。比如有次我在清理生产环境的Nginx日志时，直接用了rm命令删除正在写入的access.log，结果导致Nginx进程卡住，网站直接502了。后来才明白，原来正在被进程占用的文件，即使删除了也不会立即释放磁盘空间，反而会造成文件描述符泄漏。
清理日志的正确姿势
其实清理日志这事儿讲究方法，用对了完全不会影响服务运行。我现在的标准操作是先用lsof | grep deleted检查文件是否被进程占用，如果发现文件处于deleted状态但空间没释放，就得重启对应服务。不过更好的办法是使用日志轮转，配置好logrotate后，系统会自动帮你压缩、归档旧日志，完全不影响服务连续性。有数据显示，合理配置日志轮转能减少80%的磁盘空间占用，而且服务中断时间为零。
记得去年我们有个MySQL数据库，日志文件涨到了50GB，直接导致数据库写满挂掉。当时紧急情况下，我选择了用truncate命令清空日志文件，而不是直接删除。这样做的好处是inode保持不变，MySQL进程能继续往文件里写入，服务在几秒钟内就恢复正常了。不过这种方法也有风险，如果日志对业务很关键，建议先备份再清理。
什么时候清理日志最安全？
根据我的经验，清理日志最好选在业务低峰期进行。比如电商网站就避开双11，金融系统避开月末结算。实在要在高峰期操作的话，一定要先评估日志文件的重要性——如果是审计日志，那可得慎之又慎；如果是调试日志，影响就小很多。我一般会先查看日志内容，确认没有关键业务信息后再决定是否清理。
话说回来，与其总想着怎么清理日志，不如从根本上解决问题。我们现在都在推广结构化日志和分级存储，把ERROR级别的日志保留时间长一些，DEBUG级别的就定期清理。再加上现在流行的日志收集系统，直接把日志推到专门的存储集群，本地根本不会积压。这样既解决了磁盘空间问题，又保证了日志的完整性，服务稳定性也提升了，真是一举多得！
评论