怎样清掉云主机的日志，先别忽略这几个风险点

接手服务器运维、排查磁盘爆满，或者准备交接测试环境时，很多人都会碰到同一个问题：怎样清掉云主机的日志。表面上像是在删文件，实际会牵扯到系统稳定性、审计要求、业务排障、安全合规。清得太猛，服务可能出问题；清得太保守，磁盘空间又腾不出来。

这件事不能只盯着命令本身。先分清日志是什么、为什么要清、哪些能动、哪些最好别动，再决定是删除、截断，还是补上轮转策略。对大多数 Linux 云主机来说，这个判断顺序比具体用哪条命令更重要。

先分清你这次清理的目的

同样是在处理日志，不同场景下做法差很多。

• 磁盘空间告急：目标是尽快释放空间，但不能把正在写入的关键日志粗暴删掉，尤其是业务还在线的时候。
• 测试环境重置：可以删得更彻底一些，不过也要保留系统正常运行需要的文件和目录结构。
• 隐私或安全要求：先识别敏感内容，再按制度做脱敏、归档或删除，别看到日志就直接清空。
• 故障排查结束后的收尾：关键证据先留住，再清掉过期冗余内容，避免下次排查时被旧日志淹没。

很多人一着急就想执行 rm -rf /var/log/*。这类做法风险很高，可能删掉正在被系统或进程使用的文件，日志服务继续写不进去，认证记录也断了，后面真出问题时连排查线索都没了。

云主机上的日志通常在哪

大多数 Linux 云主机的系统日志集中在 /var/log，但服务和应用未必都老老实实写在这里。磁盘满了以后，只盯着一个目录，往往会漏掉真正的大头。

系统级日志

• /var/log/messages 或 /var/log/syslog：系统运行信息
• /var/log/secure 或 /var/log/auth.log：登录认证记录
• /var/log/kern.log：内核相关日志
• /var/log/dmesg：启动或硬件相关信息

服务类日志

• Nginx：/var/log/nginx/access.log、error.log
• Apache：/var/log/httpd/ 或 /var/log/apache2/
• MySQL：/var/log/mysqld.log 或数据目录下的错误日志
• Redis、Docker、Supervisor、Java 应用：常见在各自安装目录或运行目录下

容器与应用日志

如果业务跑在 Docker 或 Kubernetes 里，磁盘暴涨经常是容器标准输出不断堆积造成的。Docker 常见路径是：

• /var/lib/docker/containers/<container-id>/*-json.log

这类日志长得很快，也最容易被忽略。还有一种常见情况，业务程序把 debug 日志直接打到应用目录，文件名看着普通，体积却能把根分区吃满。

删、截断、轮转，处理方式别混着用

清理日志不只有“删除”一个动作。不同文件适合的处理方法不一样，混着来最容易出事。

删除旧的归档日志

像 *.gz、*.1、*.2 这种轮转后的历史日志，通常可以优先处理。它们一般已经不再被当前进程占用，删掉以后也不会影响服务继续写日志，是相对稳妥的一类清理对象。

截断正在写入的日志

访问日志、应用运行日志如果还在持续写入，直接删文件未必能立刻把空间拿回来，因为进程可能还握着文件句柄。这个时候更合适的做法是清空内容，也就是截断。文件还在，句柄不需要重建，服务稳定性更好。

补上日志轮转

只清一次，问题大概率还会回来。日志级别太高、轮转没配、容器没有大小限制，过几天磁盘还是会满。要把这个问题压住，还是得靠 logrotate、容器日志大小限制、应用自己的分割策略。

怎样清掉云主机的日志：实用处理顺序

正式动手前，生产环境最好先做快照或备份。尤其是磁盘已经满、业务已经慢的时候，人最容易误操作。

先找出谁占空间

别一上来就删。先确认是不是日志导致磁盘满，再确认是哪一类日志在膨胀。/var/log、容器目录、应用目录都要看。很多时候，系统日志只是看起来显眼，真正占空间的是业务程序连续输出的 debug 文件。

这个阶段要盯住两个点：一是大文件在哪里，二是这些文件是不是还在被写入。前者决定你先清谁，后者决定你该删还是该截断。

历史归档先动手

如果目录里堆了很多按日期切分的旧日志，或者已经压缩的历史文件，先处理它们更安全。这一步通常能先回收一部分空间，也能避免你在压力下直接去碰活跃日志。

活跃日志优先截断

像 Nginx 访问日志、Java 应用运行日志、持续增长的容器日志，如果还在实时写入，更适合清空内容，不建议直接删文件。处理磁盘告急时，这个思路很实用：先截断活跃日志，再删除历史日志。这样既能尽快腾空间，也不容易把服务写日志的动作打断。

有些服务需要重新打开日志文件

日志被轮转或清空后，部分程序需要重新打开日志文件。通常做法是平滑重载对应服务，比如 Web 服务重新加载配置，不要直接重启整台机器。整机重启看起来省事，实际影响面更大，尤其是多服务混跑的云主机。

容器环境单独处理

如果是 Docker 日志膨胀，只清理 /var/log 往往没什么效果。还要检查容器日志目录，并在后续加上日志驱动或大小限制。否则这次清掉了，下次还是同一个地方先满。

一个常见场景：磁盘100%以后怎么收拾

有一台 4 核 8G 的 Linux 云主机，跑着 Nginx、Java 服务和 MySQL。研发反馈接口超时，登录后发现根分区已经 100%。一开始大家怀疑数据库，往下查才发现是日志占用异常。

/var/log/nginx/access.log 只有几 GB，看着不小，但不是主因。真正的大头在某个 Java 应用目录下，一个 debug 日志单文件超过 80GB。除此之外，Docker 容器目录里还积着多个历史 json 日志，加起来二十多 GB。

这种时候如果图快，直接全盘删日志，服务可能当场异常，后面连为什么超时都不好追。比较稳的处理顺序是：

1. 先给云主机做快照，避免误删后没法回退。
2. 把最近 1 天的关键业务日志拷到临时归档目录，至少把需要排障的部分留住。
3. 删除 7 天前的压缩历史日志和无用归档文件，先回一部分空间。
4. 对正在写入的 Java 超大日志做截断，快速释放磁盘。
5. 清理 Docker 容器历史日志，并检查容器日志限制配置。
6. 把应用日志级别从 debug 调回 info，再补上按天切割策略。

这样处理后，磁盘占用从 100% 降到 43%，服务也恢复了。清日志时，容易卡住的地方往往是：清完以后有没有把继续增长的原因一起处理掉。

最容易踩的几个坑

把 /var/log 整个清空

这样做最省脑子，也最容易埋雷。认证日志、系统日志、服务报错信息可能一起没了。有些系统组件还依赖特定文件存在，删完以后会出现新的异常。

没看审计要求就动手

生产环境里的登录记录、操作审计、安全事件日志，很多时候不能随便清。尤其是在事故刚发生、还没完成排查的时候，日志本身就是证据。先看公司制度，再决定归档还是删除。

文件删了，空间没回来

这是运维里很常见的坑：文件已经删了，但进程还占着那个已删除文件的句柄，磁盘空间表面上没有释放。遇到这种情况，通常是处理方式不对。要么让进程释放句柄，要么一开始就用截断。

只做一次应急清理

如果长期开着 debug、没有日志轮转、容器无限写日志，那今天清完只是喘口气。过不了多久，还是一样满盘。

更稳妥的长期做法

如果你经常在想怎样清掉云主机的日志，说明当前日志管理已经该补课了。比较实际的几件事，可以尽快落下来：

• 启用 logrotate：按天、按周或按大小轮转，保留有限份数，别让历史日志无限堆。
• 限制容器日志大小：给单文件大小和保留数量设上限，避免 json 日志一路涨。
• 调整日志级别：生产环境别长期开 debug，排查结束就改回合适级别。
• 做集中式日志采集：日志转存到 ELK、Loki 或云日志服务，本地主机只留短期副本。
• 把日志目录纳入磁盘巡检：提前告警，比磁盘 100% 后再救火轻松得多。

清日志不是删除比赛。更稳妥的做法通常是先定位大文件，优先处理历史归档，对活跃日志用截断，再补上轮转和监控。测试机可以放得开一点，生产机就得把恢复、审计和服务稳定一起考虑进去。日志只要处于可控状态，云主机就不容易被这些平时没人管、出事时最致命的文件拖垮。