拨号VPS的系统日志过大如何处理?

日志这东西，平时你可能不太会注意它。它就像一个安静的记录员，默默在后台把系统里发生的每一件事都记下来。谁在什么时间登录了，哪个程序报了个什么错，网络连接断了一次又重新连上了，统统写进文件里。在你需要排查问题的时候，这些日志就是最宝贵的线索，帮你一步步找到故障的根源。

但是，这个“记录员”有个毛病——它只管记，从来不会主动收拾。你今天不清理，它就一直写。明天不清理，它还写。一个月不管它，一个日志文件撑到几个G甚至几十个G都是常有的事。当拨号VPS的系统日志膨胀到一定程度，问题就来了。磁盘空间被大量占用，系统响应变慢，严重的时候甚至会导致某些服务无法启动，因为程序连写日志的空间都没有了。

我自己就吃过这个亏。有一台跑了快半年的拨号VPS，突然有一天SSH连上去什么都做不了，敲个命令要等半分钟才出结果。查了半天发现是/var目录写满了，一多半的空间都被日志文件占了。从那次之后，我算是对“日志管理”这件事彻底上了心。今天就把这些年处理系统日志过大的经验整理出来，希望能帮你避开同样的坑。

一、先搞清楚日志到底有多大，都藏在哪儿

很多人一听说日志过大，第一反应就是跑到/var/log目录下，敲个ls -lh，看到一堆文件，但说实话不太能分清哪个是重要的，哪个是可以动的。我刚开始也是这样，看哪个都像有用的，哪个都不敢删。

后来慢慢摸出了一些门道。Linux系统里，日志文件主要分布在几个地方。/var/log/messages或者/var/log/syslog是系统的综合日志，几乎所有内核消息和系统级别的告警都会往这里面写。/var/log/auth.log记录着登录认证相关的信息，谁从哪个IP登录成功了，谁认证失败了，都记在这里。/var/log/kern.log是内核自己的日志，硬件驱动、内核模块的问题基本都能从这里找到线索。

还有一些应用会自己建目录，比如Nginx或者Apache的日志通常在/var/log/nginx和/var/log/apache2下面，数据库的日志在/var/log/mysql或者/var/log/postgresql下面。如果你跑了一些第三方软件，它们可能也会在/var/log下建自己的目录。

怎么看这些日志占了多少空间呢?用du这个命令就行。du -sh /var/log可以一眼看到整个日志目录的大小。如果你觉得还是太笼统，可以用du -h --max-depth=1 /var/log | sort -hr，它会列出/var/log下每个子目录的大小，并且从大到小排好序，哪个目录是“大户”，一目了然。

二、紧急处理：系统快被日志撑爆了怎么办

当你发现系统已经因为日志过大开始出问题的时候，比如磁盘使用率到了95%以上，或者系统卡得不行，这时候你需要的是“急救”，不是慢慢分析。

最快的方法是直接清空那些最大的日志文件，注意我说的是清空，不是删除。为什么要清空而不是删除呢?因为很多程序在启动的时候会打开日志文件，并且一直保持着这个文件的“句柄”。如果你直接把文件删了，程序那边并不知道，它会继续往那个已经不存在的文件里写日志，反而可能导致更奇怪的问题。

清空日志文件的命令很简单：> /var/log/syslog。这条命令会把syslog文件的内容清空，但文件本身还在，程序可以继续往里写。如果你不确定哪个文件最大，可以先用du -h /var/log/* | sort -hr看一圈，挑最大的那个先清空。

对于systemd管理的系统，还有一个更彻底的清理方法。journald是systemd自带的日志系统，它存的日志不在/var/log下面，而是以二进制格式存在/var/log/journal目录里。用journalctl --vacuum-size=100M这个命令，可以立刻把journal日志压缩到100M以内，旧日志自动删除。这个命令的效果几乎是立竿见影的，我遇到过好几次磁盘告警，跑完这条命令瞬间释放了好几个G的空间。

如果你连命令都敲不了，或者SSH已经登不进去了，那就只能通过VPS控制面板的VNC或者救援模式进去操作。救援模式下你的原系统分区会被挂载到一个目录下，你找到那个目录下的/var/log，同样用清空的命令处理一下，然后重启，系统就能恢复正常了。

三、长效管理：让日志学会“自己收拾自己”

紧急处理只能解决眼前的问题，如果你不改设置，过不了多久日志又会涨起来。你需要一套机制，让日志文件长大到一定程度之后，自动压缩、自动删除、自动轮转。

Linux系统里负责这个工作的工具叫logrotate。绝大多数发行版都预装了它，并且已经为系统的主要日志配置好了轮转规则。但默认的规则往往比较“宽容”，比如日志每周轮转一次，保留四周的旧日志。对于磁盘空间紧张的拨号VPS来说，这个设置可能还是太奢侈了。

logrotate的配置文件在/etc/logrotate.conf，而各个应用的独立配置通常放在/etc/logrotate.d/目录下。你可以自己调整轮转的频率、保留的份数、是否压缩等参数。

举个例子，对于/var/log/syslog这个文件，默认可能是每周轮转一次，保留四次。如果你希望更激进一些，可以改成每天轮转，只保留三天。在配置里加上daily和rotate 3就行。另外加上compress选项，让logrotate把轮转出来的旧日志用gzip压缩一下，压缩之后文件大小通常只有原来的十分之一甚至更少。

我个人的习惯是这样配置的：

/var/log/syslog {

daily

rotate 7

compress

delaycompress

missingok

notifempty

create 644 syslog syslog

}

解释一下几个关键选项的意思。daily表示每天轮转一次，rotate 7表示保留七份旧日志，compress表示压缩旧日志，delaycompress是配合compress用的，意思是上一次轮转出来的日志先不压缩，等下一次轮转的时候再压缩，这样做的好处是避免正在被某些程序使用的日志文件被压缩导致异常。missingok意思是如果日志文件不存在就跳过，不报错。notifempty意思是如果日志文件是空的就不轮转。create表示轮转之后创建一个新的空日志文件，并设置好权限和属主。

配置好之后，你可以用logrotate -d /etc/logrotate.conf来测试一下配置有没有语法错误。-d是调试模式，不会真的执行，只是把会做什么事打印出来给你看。确认没问题之后，logrotate会每天由cron定时任务自动触发，你不用再操心了。

对于像我之前提到过的journald日志，同样可以设置大小上限。编辑/etc/systemd/journald.conf文件，找到SystemMaxUse这一行，去掉注释，设置一个你认可的上限。我一般设成500M，这样不管系统怎么跑，journal日志最多只会占用500M的磁盘空间。改完之后执行systemctl restart systemd-journald重启服务，新的设置就生效了。

四、从根源上减少不必要的日志

轮转和清理是属于“被动防守”，还有另一个思路是“主动减量”——让那些不那么重要的程序少写点日志。

很多应用都有日志级别的概念。DEBUG级别会记录最详细的信息，INFO级别记录一般的运行状态，WARNING只记录警告和错误，ERROR只记录错误。如果你发现某个应用每秒钟往日志里写好几行DEBUG信息，而你又从来不看这些信息，那完全可以把日志级别调到WARNING甚至ERROR。

以常见的Nginx为例，你可以修改配置文件里的error_log指令，把级别从info改成warn。对于Python脚本，logging模块里设置日志级别为logging.WARNING。对于rsyslog或者syslog-ng这类系统日志服务，你也可以配置过滤规则，比如把某些频繁产生的、又不重要的消息直接丢弃不记录。

还有一种情况是你自己的脚本或者程序在疯狂写日志。比如写了一个循环，循环里面每执行一次都往日志里写一行“运行成功”。这种高频写入不仅消耗磁盘空间，还会影响磁盘I/O性能。我建议生产环境下的脚本，只在关键步骤或者发生错误的时候才写日志，正常的业务流水线没必要每步都记。

五、把日志分流到其他地方

如果你的业务确实需要保留大量的日志用于分析和审计，而拨号VPS本地的磁盘空间又实在有限，那可以考虑把日志“搬”出去。

一个常见的做法是配置rsyslog或者syslog-ng，把日志实时发送到远程的日志服务器上。本地只保留最近几天的日志用于紧急排查，历史日志全部集中存储到另一台磁盘空间充裕的服务器上。这样既满足了保留日志的需求，又不会拖累拨号VPS本身的磁盘容量。

另一个更轻量级的做法是写个cron定时任务，每天凌晨把昨天的日志打包压缩，然后用scp或者rsync同步到远程存储或者对象存储服务上。同步完成之后，再清空本地的日志文件。这种做法稍微有点延迟，但实现起来比较简单，也不需要搭建额外的日志服务。

六、一个真实案例：从100%磁盘占用到稳稳当当

去年有一个做数据分析的朋友找到我，说他的一台Linux拨号VPS突然完全没法用了。SSH连上去就卡住，重启之后能撑几个小时然后又卡死。我让他进控制面板看了一眼磁盘使用率，/分区已经100%了。

救援模式进去之后，我用du一查，发现/var/log/journal目录占了好几个G，/var/log/nginx目录也占了将近4个G。再看nginx下面的access.log，这个文件居然有3.2个G。打开一看，每一秒都有好几条访问记录，全是某个爬虫脚本在疯狂请求同一个接口。

这个朋友平时不看日志，也不知道nginx的访问日志会涨得这么快。那个爬虫脚本跑了两个月，访问日志就攒到了3个多G。再加上journal日志从来没清理过，两块加起来直接把磁盘塞满了。

解决方案不复杂。先用journalctl --vacuum-size=200M把journal日志压缩到200M，然后清空nginx的access.log，磁盘使用率瞬间降到了50%以下。接着我给nginx配置了logrotate，每天轮转一次，保留三天的日志，并且开启压缩。对于journald，我把SystemMaxUse设成了300M。最后在crontab里加了一条每周执行一次的磁盘使用率检查脚本，超过80%就发邮件提醒。

改完之后到现在已经大半年了，那台VPS再也没有因为日志问题卡死过。磁盘使用率长期稳定在60%左右，日志该保留的保留，该清理的自动清理，朋友也不用再操心这些事情了。

总结

系统日志过大，本质上不是Linux系统的问题，而是管理习惯的问题。日志是系统安全运行的重要保障，你不能不要它，但也不能放任它野蛮生长。

处理这个问题的核心思路可以总结成三句话：用logrotate做好自动轮转，用journalctl的大小限制控制上限，用日志级别调整减少写入量。做好了这三件事，你就再也不用担心日志会把磁盘撑爆了。

当然，偶尔登录系统看一眼日志目录的大小，也是个不错的习惯。就像你隔段时间会打扫一下房间一样，花不了多少时间，但能让你的VPS一直保持在一个清爽、健康的状态。