磁盘写满导致宕机这件事，光靠告警根本兜不住，真正有效的方案是把“磁盘空间使用率、inode消耗速度、日志增长速率、IO异常状态”四项巡检做成自动化兜底机制，在写满之前就介入清理或扩容。
磁盘写满为什么总在深夜发生，而巡检却形同虚设
多数运维团队不是没有巡检，而是巡检方式出了问题，行业共识认为，定时巡检只能发现问题，无法阻止问题，一个常见的场景：凌晨两点，业务日志量突增，磁盘使用率从早上巡检时的65%飙升到100%，数据库直接只读，网站打不开，等早上上班看到告警,业务已经挂了四五个小时。
更扎心的是，磁盘写满并不是“突然”发生的，任何一个分区从60%到100%都需要一个过程，这个过程可能是几小时，也可能是几天，如果巡检只停留在“每天看一眼使用率”这个层面,那本质上是在赌运气。
巡检要想真正“兜住”，必须回答三个问题：看什么指标、多久看一次、看完之后自动做什么，三个问题缺一个,巡检就是走过场。
只看空间使用率是最大的盲区
很多运维朋友对“磁盘满了”的理解就是df -h里那一列百分数，但实际生产环境里，inode耗尽导致宕机的案例不在少数，inode是文件系统的索引节点，存的是文件元数据，当磁盘上小文件数量暴增，比如临时文件、缓存文件、容器日志碎片，inode会先于空间被耗尽，表现出来就是磁盘明明还有几十G，但创建不了任何新文件,数据库直接报错。
这解释了为什么有人问“linux磁盘写满怎么排查”时，老手第一反应就是让你先跑df -h再看df -i，两个命令输出对比一下，如果空间使用率正常但inode使用率接近100%,那问题就在小文件上。
巡检项里必须同时包含空间使用率和inode使用率,缺一个都是在埋雷。
磁盘巡检到底要巡检哪些具体项
核心逻辑是：从“看结果”变为“看趋势”，不光是看当前使用了多少，还要算清楚按照当前增长速度,多久会写满。
以下是实际生产环境中建议覆盖的巡检维度：
- 空间使用率：用
df -h看各分区使用百分比，这是最基础的 - inode使用率：用
df -i查看，重点盯/var、/tmp这类临时文件高发区 - 日志增长速率：用
du -sh /var/log/或者find按时间排序，找出近期增长最快的文件 - IO等待时间：用
iostat或top观察wa值，磁盘写满前往往伴随IO性能劣化 - 文件句柄数：用
lsof统计，某个进程打开的句柄数异常攀升常常是先兆
这五个维度不是并列关系，而是配合关系，空间和inode看的是“存量”，日志增长和IO等待看的是“增量”,文件句柄数则是辅助判断是否有异常进程在疯狂写数据。
执行频率怎么定才能既及时又不影响业务
巡检太频繁会消耗系统资源，太稀疏又失去意义，实践中比较成熟的方案是
分层巡检：
- 分钟级（1-5分钟）：只做轻量检查，比如读
/proc/meminfo或df的缓存输出，不跑重命令 - 小时级：全量检查空间和inode，记录历史数据用于趋势对比
- 每日级：深度分析日志增长排名、清理策略执行情况、定时任务是否正常
这种分层设计能让巡检“重而不笨”，分钟级巡检负责兜底紧急情况，小时级巡检负责发现趋势,每日级巡检负责复盘和调优。
告警阈值怎么设置才能既准确又不误报
告警阈值设高了，磁盘写满了才喊，等于没设；设低了，天天半夜响铃，运维直接拉黑告警通道。阈值设置的核心不在于“多少百分比”，而在于“按照当前增长速度，剩余可用时间”。
比如A机器磁盘剩余空间有50G，但日志每天写30G，剩余时间不到两天；B机器同样剩余50G，但每天只写1G，剩余时间五十天，同样都是剩余50G,风险等级完全不同。
建议采用双阈值策略：
- 预警阈值（剩余可写时长小于72小时）：通知运维，触发自动清理预案
- 告警阈值（剩余可写时长小于24小时）：进入紧急流程，自动介入清理，通知负责人确认
换算下来，生产环境高写入机器通常把磁盘使用率预警设在75%-80%，告警设在90%左右，但固态盘和机械盘的性能特征不同，文件系统也有差异,具体数值要根据自己机器的情况跑几天数据再定。
常用命令和实操路径
这里给一套可直接落地的巡检命令组合：
# 查看空间使用率
df -h
# 查看inode使用率
df -i
# 找出/var下增长最快的目录
du -sh /var/ | sort -rh | head -10
# 查看最近7天被修改的大文件
find /var/log -type f -mtime -7 -size +100M -exec ls -lh {} ;
把这些命令封装成脚本，配合crontab或者systemd timer定时执行，输出结果写入独立日志文件，有条件的团队可以直接接入Prometheus + Grafana，node_exporter本身就采集了磁盘空间和inode指标,告警规则用PromQL写也行。
自动清理机制比巡检本身更值钱
巡检只是发现问题的眼睛，真正兜住磁盘写满这件事的，是巡检触发后的自动清理能力,建议建立三级自动处置机制：
- 一级处置：日志轮转，检查
/etc/logrotate.conf和/etc/logrotate.d/下的配置，确保所有应用日志都配置了按大小或按天轮转，很多磁盘写满事故，根源就是某个应用日志忘记配logrotate,单文件涨到几十个G。 - 二级处置：定时清理临时文件。
/tmp目录和各类缓存目录，用tmpreaper或cron脚本定期清理超过N天未访问的文件，容器环境还要关注/var/lib/docker/containers/.log,这个文件经常是磁盘杀手。 - 三级处置：自动扩容兜底，云上环境用云盘的API做自动扩容脚本，触发告警后自动增加磁盘容量并扩展文件系统,裸金属或虚拟化环境则预留热备磁盘。
这套机制跑起来之后，磁盘写满导致宕机的概率会大幅下降，但要注意，自动清理机制本身也要被巡检覆盖清理脚本挂了，比不清理还隐蔽,建议每次巡检时顺带看一眼上次清理任务是否成功执行。
磁盘巡检脚本如何做到不误伤业务
自动清理最怕的是删错文件，有些日志文件正被进程占用，删了之后文件句柄还在，磁盘空间不会释放，但业务可能已经异常，这就是为什么处理“磁盘满了如何清理”时，第一原则是用truncate而不是rm在用占用中的日志文件：
# 安全清理被占用的日志文件，不清除文件句柄 truncate -s 0 /var/log/nginx/access.log
另一个容易踩的坑是删了正在写入的临时文件，导致应用异常退出，所以清理脚本要设置白名单机制明确哪些目录可以自动清理，哪些只能告警，比如/var/log可以自动轮转，/tmp可以自动清理7天前的文件，但应用数据目录、数据库目录、监控数据目录只告警不自动处理。
巡检报告怎么设计才有参考价值
巡检报告不需要花哨，但要能回答“今天和昨天比，风险是升高还是降低”,建议表格记录几个关键字段：
| 字段 | 说明 |
|---|---|
| 分区 | 被巡检的挂载点 |
| 总容量 | 分区总大小 |
| 已用空间 | 当前使用量 |
| 24小时增长量 | 与昨天同时间对比的增量 |
| 预计写满天数 | 按当前增速估算的剩余时间 |
| inode使用率 | inode占用百分比 |
| 自动处置结果 | 本次巡检是否触发清理动作及结果 |
用这份表格连续记录两周，就能看出业务增长的周期性规律，也能为后续容量规划提供依据。巡检报告最有价值的部分是趋势数据，而非某个时间点的快照。
磁盘写满宕机后如何快速恢复
即便做了全套预防，也难免遇到极端情况，真到了磁盘100%写满、服务宕机的时刻,恢复顺序很关键：
第一步：找到可释放空间，执行df -h确认哪个分区满了，然后du -sh / 2>/dev/null | sort -rh | head逐层定位大目录,优先清理日志和临时文件。
第二步：处理删除后空间不释放的问题，用lsof | grep deleted找到被删除但仍被进程占用的文件,确认后重启对应进程或服务。
第三步：恢复服务，确认空间释放后，依次启动数据库、中间件、应用服务，启动顺序按依赖关系,先基础后业务。
第四步：复盘原因，修补巡检盲区，这次是怎么撑爆的，是预测不足还是清理脚本失效,把根因修复后补充进巡检逻辑。
磁盘空间巡检工具对比与选型建议
对于有得选的情况,常用的磁盘巡检工具方案有以下几类：
- 命令组合方案：
df+du+crontab，零成本，适合小型业务或临时应急 - 传统监控方案：Zabbix/Nagios这类老牌监控工具，自带磁盘监控模板，优点是成熟稳定，缺点是配置稍重，告警能力一般
- 云原生方案：Prometheus + node_exporter + Alertmanager，灵活度高，适合容器化和微服务架构，社区活跃，告警规则可以精细化
- 商业运维平台：云厂商自带的监控中心，如简米云监控、酷番云监控，开箱即用但按量计费
选型建议很简单：现有监控体系里有的能力先复用，没有的再补，不要为了巡检专门上一套新平台,重运维本身就是一种风险。
磁盘巡检常见误区和避坑建议
- 只监控空间不监控inode，上面已经强调过，inode耗尽一样会宕机，且排查起来更隐蔽
- 磁盘使用率阈值常年不变，业务在增长，数据量在变，阈值要每月回顾一次
- 清理脚本不做演练，脚本写完丢服务器上就以为万事大吉，结果日志路径变了、权限变了、目录被重置，脚本早就不生效了
- 忽视小容量分区，根分区和数据分区往往最容易受关注，但
/boot、/var这类独立分区有时反而先被写满
这些坑每一个在真实生产环境里都出现过，巡检是持续性工作，不是上线了就一劳永逸，每月至少花半小时审视一遍巡检配置的合理性。
磁盘写满导致宕机常见问题解答
磁盘写满前会有哪些预兆信号需要关注？
最典型的信号是磁盘使用率呈现稳定上升趋势而非波动变化，正常情况下磁盘使用率每天有小幅波动，但如果连续三天持续走高且没有下降趋势，就是预警信号，另一个容易被忽视的预兆是IO等待时间（wa值）逐渐攀升，大量写入操作导致IO拥塞时，往往离写满不远了，日志中频繁出现"no space left on device"也是直接提示。
磁盘空间巡检脚本应该如何设置定时任务？
核心原则是频率要适配写入速度，写入频繁的业务建议每5分钟跑一次轻量巡检，仅检查总量；每小时做一次深度检查记录趋势，crontab配置示例：/5 /usr/local/bin/disk_check_light.sh，另外用find命令加上-size参数，每天扫描一次新增的大文件,找出潜在风险点后自动触发清理动作。
磁盘清理后空间没有释放是怎么回事？
多数情况下是删除的文件仍被进程占用，用lsof | grep deleted查看被删除但仍打开的文件句柄，找到对应进程ID后重启该进程即可释放空间，行业共识认为，这类问题最容易发生在日志文件上，因为日志持续被进程写入，直接rm掉文件后fd仍然保留，空间无法真正释放，推荐用truncate -s 0 日志文件路径代替rm操作，既清空内容又保留文件句柄,不影响业务进程。