是谁把我的服务器硬盘撑爆了！是谁！

大家好，我是程序员鱼皮。之前有同学问：为什么反复强调学编程时一定要把项目上线？而不是跟着教程敲完、能本地运行就结束了？

答案很简单，企业中的项目都是上线的，你进入工作后要处理很多线上的问题。很多 Bug 是只有项目上线后才会经历的，也只有处理过这些 Bug，你的经验值才会持续上涨。

今天给大家分享的就是我自己处理一个线上问题的故事。

故事 事故

我估计不少同学都经历过自己电脑硬盘空间不足的烦恼吧，但想必大多数程序员朋友没有经历过服务器硬盘空间不足的问题。

我还真经历过，记得那是我在腾讯做开发的第二年，有一天突然收到了一个告警，说是我的服务器硬盘空间即将被占满，让我及时处理。

收到这个告警时，我是懵逼的，因为我部署到这个服务器上的项目并没有涉及什么文件写入，公司服务器硬盘还挺大的，怎么突然空间就满了呢？

于是我使用 Linux 命令进一步排查，比如下面这个命令：

du -h --max-depth=1 | sort -hr | head -n 10

这行命令的作用是：列举磁盘上占用空间前 10 的目录和占用空间大小。

一下就查到了元凶，竟然是某个项目的日志文件，占了 70% 的空间！

我相信大家平时自己做项目的时候，很少会关注日志文件占用的大小，一般项目量级不大也没什么影响。但如果项目长期运行，哪怕每天 100 mb 的日志，一年也会占用几十个 G 了，不容小觑。

有意思的是，产生这些日志文件的项目，还不是我自己的，是其他用这个服务器的同事的项目！所以为啥说项目要尽量独立部署、可以用容器去做隔离呢，共用服务器一旦出事，所有项目就 “连坐” 了。

解决方案

硬盘不足可能会给程序带来很多问题，比如项目无法启动、临时文件无法创建、日志文件无法写入等等。轻则影响业务功能，重则服务宕机，所以不得不引起重视。

正好昨天编程导航的鱼友问我：“自己公司的项目每天几十 G 的日志，硬盘不足，怎么处理？”

那下面我就分享下自己关于日志处理的经验。

1、日志控制

这是最简单方法，比如精简日志的内容：尽量使用简短的英文提示语代替中文，能查询出关键信息即可，能省则省。

还有对日志级别的控制。日志一般分为DEBUG、INFO、WARN、ERROR 等级别，可以根据不同的环境动态调整输出级别，比如在生产环境通常设置只输出 INFO 或 WARN 及以上等级的日志，在开发环境或诊断问题时才临时输出 DEBUG 级别的日志。

2、日志轮转

使用日志轮转机制（logrotate），可以根据时间或文件大小自动讲日志进行切分和压缩、甚至是清理，防止日志无限增长。

比如按照日维度和日志级别对日志进行切分和压缩，可能看到下面的文件列表：

• xxx.ERROR.2024-05-23.0.log（被切分）
• xxx.ERROR.2024-05-23.1.log
• xxx.ERROR.2024-05-23.2.log
• xxx.INFO.2024-05-23.0.log（分级别）
• xxx.ERROR.2024-04-01.zip（被压缩）

很多日志框架都自带了日志轮转功能，去网上找一段配置就可以了，不多说。

3、日志清理和转储

可以定期将部分历史日志进行清理，或者压缩后移动到更便宜的存储上（比如对象存储的冷存储），用程序写个定时任务或者脚本就能实现。

也可以自己设置一些策略，比如 7 天清理一次 INFO 级别的日志、14 天转储一次 ERROR 日志。

4、日志管理系统

自己做项目时，为了方便，日志一般写入并存储到服务器上即可。但如果日志量级大了，可能就要考虑使用集中化的日志管理系统，比如典型的分布式日志 ELK（Elasticsearch + Logstash + Kibana），可以将日志统一采集、存储到多台服务器上并支持在线分析。这样不仅能够减轻单台服务器的磁盘压力、便于扩容硬盘、还可以更方便地进行日志搜索和分析，不用自己写 Linux 命令从日志文件中提取文本了。

但搭建和维护 ELK 的成本是比较大的，小公司未必要使用。大厂一般会有统一的分布式日志收集系统，而且由专门的技术团队维护，我们各个业务侧的开发同学直接通过 SDK 或日志采集 agent 来将自己的日志接入到系统即可。这样不用担心因为日志占用磁盘问题导致项目故障。但是使用日志收集系统不意味着我们就能放肆地浪费空间了，维护团队也会设定一个规则，比如日志只能保留一段时间，如果要长期保留，可能要消耗自己部门的预算之类的。

5、选择合适的日志框架

有些日志框架可能硬盘空间不足后就会报错、甚至阻塞程序运行、让 CPU 负载超标等。建议选择像 Logback 这种日志框架，在硬盘不足时，不会写入日志，也不会影响程序；等有硬盘空间了，又会继续写入。