【异常】OpenClaw线上服务器磁盘高位告警故障排查与解决指南凌晨两点十七分监控钉钉群突然开始震动OpenClaw线上业务节点的磁盘使用率告警被触发88%的数值已经连续挂了11个小时。这个数字一眼看上去不致命但配上“连续11小时高位运行”就很麻烦了——说明不是瞬时突发流量造成的抖动而是有什么东西一直在持续吃磁盘空间。如果放任不管大概率会从88%慢慢爬到95%以上到时候日志写不进去、临时文件落不了盘、数据库checkpoint做不了整个服务可能会以一种很难看的方式挂掉。这篇文章我把这次排查的思路和操作完整记下来从告警触发到定位元凶再到清理释放、长期治理全部走一遍。如果你手头也有类似的服务节点恰好磁盘告警了不知道从哪里下手可以参考这条路径起码能帮你少走几个弯路。1. 故障现象与风险预判1.1 告警指标解读88%和“连续11小时”意味着什么先看监控系统给出的原始告警信息磁盘使用率88%持续周期11小时告警级别为高位警告。这两个数字需要分开解读。88%本身是一个危险临界值。对于机械盘来说超过90%后文件分配会变得碎片化随机写入性能明显下降对于固态盘而言剩余空间不足10%时垃圾回收机制会频繁触发写放大效应加剧IO延迟成倍上升。对于OpenClaw这类需要持续写入业务数据的线上节点88%已经逼近了故障临界线。“连续11小时”这个时间维度更关键。如果是几分钟内的临时波动可能是某个大文件在写、某个临时任务在拉数据系统会自动释放。但连续11小时维持高位说明存在一个持续的写入源或者遗留的体积占用它不会自己消失。这个特征基本排除了瞬时流量造成的偶发告警指向的是日志积累、数据堆积、残留文件这类慢性的空间吞噬问题。1.2 磁盘高位运行的连带风险磁盘空间告急最直接的恐怖之处在于它永远不是独立故障而是一连串故障的导火索。OpenClaw节点的核心服务一旦因为磁盘满而崩掉影响面远比你想象的大。第一日志系统会先遭殃。像常用的日志采集组件在磁盘空间耗尽时无法写入缓冲区轻则丢日志重则进程直接挂掉。而日志挂了之后排障就变成了盲人摸象什么都看不到。第二数据库或消息队列的落盘操作会阻塞。以常见的中间件为例它们在写入前会预留空间来保证一致性磁盘不足时直接拒绝服务消费者和生产者的链路彻底断裂。第三自动清理机制会启动保护但保护动作本身可能引发问题。比如某些数据组件在磁盘达到阈值时会自动触发缩容或清理任务但这种被逼无奈的操作往往没有经过充分评估可能把热数据也一并清掉。我的经验是磁盘使用率跨过85%以后需要按紧急故障处理不要再等下一个监控周期去观察。接下来的一切操作都围绕“尽快安全释放空间”这个目标展开。2. 快速确认现状从告警到定位现场2.1 第一步登录节点查看整体使用率收到告警后我第一时间登录OpenClaw线上节点先用基础命令确认整体情况而不是直接漫无目的地去找大文件。df -h这条命令的输出会列出所有挂载点的使用情况。重点看根分区/因为大多数业务日志、临时文件、容器数据都落在系统盘上。我在这次排查中看到的结果是Filesystem Size Used Avail Use% Mounted on /dev/vda1 100G 88G 12G 88% /根分区总共100G已用88G剩余12G。这个剩余量撑不了太久特别是如果日志还在持续增长的话。我顺手又执行了df -i查看inode使用情况防止出现“空间还有但文件创建不了”的尴尬场景。df -i这里说明一下为什么要查inode。有些场景下磁盘空间明明还有剩余但应用就是报“No space left on device”原因就是inode用尽了。大量小文件比如临时缓存、消息队列的堆积文件会把inode耗尽。这次排查中inode使用率在合理范围内所以主线还是放在大文件占用上但我建议大家养成df -h和df -i一起看的习惯。2.2 第二步锁定空间大头所在的目录整体使用率确认后进入根目录逐层向下扫描找出哪个目录占用的空间最大。这一步的目的是缩小目标范围而不是漫无目的地到处翻找。cd / du -sh * 2/dev/null | sort -rh | head -20这里du -sh会统计每个一级目录的占用总量sort -rh按数值大小倒序排列加上2/dev/null是为了屏蔽权限不足的报错信息避免干扰视野。实际输出的前几行是48G /data 22G /var 12G /usr 5G /opt/data占了大头48G/var紧随其后22G。这个分布很典型业务数据与日志集中在/data系统日志和缓存集中在/var而/usr这类系统目录基本可以跳过因为它的体积来源于软件安装通常不会突然增长。看到这个结果排查方向就很明确了先看/data里是什么在膨胀再看/var/log是不是日志堆积。2.3 一步一步往下钻取找最大目录而不是最大文件这里要分享一个经验在大目录套小目录的层级结构里直接找“最大文件”很容易漏掉真正的元凶因为很多垃圾是分散的小文件堆积出来的。正确做法是一层层往下剖析每层都看当前级别下哪个子目录最占空间。我继续执行了du -sh /data/* 2/dev/null | sort -rh | head -10输出显示30G /data/applogs 12G /data/backup 4G /data/service排名第一的是/data/applogs30G这基本坐实了日志堆积是本次磁盘告警的元凶。到这一步大方向已经锁定剩下的就是进入日志目录看看哪种日志是“空间杀手”。3. 定位核心占用日志、容器与临时文件3.1 日志目录永远的第一怀疑对象进入/data/applogs后我按文件大小查看了最大的几个文件ls -lhS /data/applogs | head -15-S参数会按文件大小倒序排列。结果中有几个文件非常扎眼这里写一个最有代表性的-rw-r--r-- 1 app app 26G Sep 28 08:00 service.log单文件26G几乎是它一个文件把磁盘空间顶上去的。这是一个典型的业务日志文件打开一看里面全是一条错误堆栈在反复打印。这种问题比“日志太多”更棘手——它不是日志量大而是代码逻辑疑似陷入了死循环触发了异常反复写入。这里要说清楚一个处理原则单文件巨大不能直接用rm删掉就完事因为很多应用进程会保持对日志文件的文件句柄。rm之后磁盘空间不会立即释放df -h看到的还是占用状态必须要把进程重启或者用truncate清空才能让空间真正回来。这个细节对于线上节点特别重要下面实操部分我会再展开。3.2 容器相关目录overlay 层的隐形膨胀如果你在du扫描时看到/var/lib/docker或者类似的容器数据目录占了大头那优先级也很高。容器场景下的磁盘吃紧通常来自三个层面容器日志json-file驱动、镜像层缓存、以及容器内部写入但未清理的临时数据。以/var/lib/docker为例du -sh /var/lib/docker/* 2/dev/null | sort -rh | head -10如果看到containers目录很大多半是容器日志的问题如果是overlay2目录很大可能是镜像或容器可写层堆积。针对容器日志常见的处理方式是开启 log rotation日志轮转这个下面会讲到。而镜像层的清理则需要使用镜像清理命令把悬空镜像和不再使用的缓存层清掉。这次排查中/var/lib/docker占用的空间不是最大的但我在另外几次排障中遇到过它直接吃掉60%磁盘空间的情况所以这个位置一定要纳入检查范围。3.3 临时文件与缓存容易忽略的角落日志和容器之后第三个容易出问题的地方是临时目录。OpenClaw节点上有一些定时任务在处理数据如果任务异常中断临时文件可能残留下来。du -sh /tmp /var/tmp 2/dev/null这次扫描发现/tmp下有一个5G左右的任务中间文件看起来确实是某次数据处理任务中断后遗留的。这类临时文件的特点是不容易引起关注因为它们的生命周期通常是瞬时的但一旦异常就会一直躺在磁盘上。3.4 核心转储文件与dump文件再提一个新手容易忽略的核心转储文件。如果节点上的某个进程发生过崩溃系统默认会在工作目录或指定目录生成core文件。一个 core 文件的大小可能等于进程的内存占用动辄几个G甚至十几个G。find / -xdev -name core -o -name core.* 2/dev/null如果发现这类文件先确认对应进程是否还需要诊断确认不需要后即可安全删除。这次排查中没有发现 core 文件但我在之前的项目中见过 core 文件占掉20多G空间的案例值得列入常规检查。4. 清理与释放空间安全回收4.1 日志安全清理truncate 优先于 rm定位到/data/applogs/service.log是主要的空间占用者之后我开始的清理操作是有顺序的不是简单粗暴删文件。对于正在被进程持有的日志文件用truncate而不是rm是更安全的选择。truncate会把文件内容清空但保留文件本身和进程的文件句柄应用进程不会受到影响也不会出现“文件已删除但空间不释放”的悬空状态。truncate -s 0 /data/applogs/service.log执行后立刻用df -h确认Filesystem Size Used Avail Use% Mounted on /dev/vda1 100G 62G 38G 38% /使用率从88%直接落到了38%空间释放了26G。那个巨无霸日志文件被清空后磁盘压力瞬间就缓解了。但这里要提醒一句truncate只是治标如果应用还在继续往这个文件里打日志它还是会慢慢涨回去。所以清完之后一定要去看那个日志对应的服务为什么一直在输出。4.2 处理掉日志背后的代码问题我打开service.log的尾部内容确认了反复出现的异常堆栈指向的是一个数据同步模块。从日志模式上看应该是某次外部接口调用超时后模块没有做熔断而是在循环里反复重试每次都把完整的参数与堆栈写入日志。处理方案分两步第一步临时止损。调整应用日志级别将该模块的日志输出从DEBUG调整为WARN减少瞬时写入量。这一步通过配置中心下发不需要重启进程能立即生效。第二步修复逻辑。在代码层面给重试逻辑增加最大次数限制并引入指数退避策略避免在短时间内高频重试。修复完成后发版上线观察日志增长曲线是否恢复正常。这一步往往被很多人忽略但它才是本次告警真正的病根。只清日志不修复问题等于只打扫了垃圾但没有关上水龙头过两天告警又会回来。4.3 临时文件与无用备份清理日志清理完成后我又处理了之前发现的/tmp遗留临时文件以及/data/backup下的过期备份。这里说一下备份清理的原则线上备份保留周期通常按“最近7天每日完整备份 最近4周每周备份”来设计超过这个周期的历史备份可以压缩或者清除。find /data/backup -type f -mtime 30 -delete这条命令会删除30天前的备份文件。执行前我特意检查了备份任务的状态确认最新的备份产物完整存在才敢放心删除旧文件。我的一条经验是删除备份前一定先确认当前备份是可用的。否则删完旧文件才发现新备份写坏了那才是灾难。4.4 清理后的空间验证所有清理操作结束后要做一次完整的空间确认和文件系统完整性检查df -h df -i同时观察了监控面板上磁盘使用率的趋势曲线。使用率从88%开始下降后曲线逐步走平说明不仅是空间释放了日志写入量也降了下来问题确实得到了控制。对于使用 LVM 等逻辑卷管理的节点如果清理后发现根分区还是不够用还可以考虑扩展逻辑卷和文件系统。不过这次场景是空间释放足够了没有走扩容这一步。扩容属于另一套操作流程建议在明确评估存储需求后再动手不要因为一次告警就拍脑袋扩容。5. 常见问题与排查技巧实录5.1 为什么删了文件磁盘空间没有释放这个坑值得单独拿出来讲。很多人在清理空间时遇到的问题是rm删除了一个很大的日志文件然后df -h一看空间使用率压根没变。原因就是前面提到的文件句柄问题。当一个文件被进程打开后进程持有该文件的 inode即使从目录中删除了文件名inode 在进程关闭或退出前不会被释放。此时磁盘空间看起来依然是占用的。正确做法有两个使用truncate -s 0清空文件内容而不是删除文件这个对运行中的服务最友好。或者执行rm后重启持有该文件的进程让文件句柄关闭空间才会真正释放。判断哪些文件被进程持有可以用下面这条命令lsof | grep deleted如果看到大量deleted状态的文件说明这些就是用rm删掉但还没释放空间的文件找到对应进程PID后重启或让其重新加载即可。5.2 inode耗尽导致的空间假象还有一个常见的坑是“空间有剩余但无法写入文件”。如果创建的临时文件数量特别多操作系统又没有及时回收可能导致inode被全部占满。排查方法df -i如果IUse%接近100%就算df -h显示还有剩余空间应用一样会报磁盘写满错误。这时候的清理思路就不是删大文件了而是通过find / -xdev -type f | wc -l统计文件数量再定位到具体目录去批量清理无效小文件。5.3 日志轮转没有生效的原因很多系统其实配置了 logrotate但日志还是把磁盘顶爆了这个现象背后有几个常见原因。第一个是配置的轮转周期过长。比如每天轮转一次的日志如果单日生成量达到20G那它增长的上限本身就是20G设置轮转时没有评估单日日志量导致没等轮转触发磁盘已经被写满了。第二个是进程没有发送信号给应用。logrotate 轮转后通常要执行copytruncate或者发送信号让应用重新打开日志文件。如果这一步没配好应用还在往已删除的日志文件句柄里写数据轮转就形同虚设。第三个是dateext与compress的组合配置带来的空间突增。开启dateext后日志轮转会以日期命名新文件如果同时开启压缩压缩过程需要临时空间在磁盘本身就紧张时会产生额外冲击。遇到严格的低空间环境可以延迟压缩或者提前保留充足的预留空间。5.4 一条命令快速定位大目录的思路如果不想一层层du扫描可以用单条命令来一次性定位。我的习惯是du -h --max-depth2 / 2/dev/null | sort -rh | head -30这个命令能看到根目录下两层目录的空间占用排行榜基本能把98%的“空间大头”一眼找出来。它的缺点是对磁盘IO有一定压力在业务高峰期执行会短暂影响磁盘性能建议在低峰期运行。6. 容量规划与监控体系优化6.1 从一次告警到一套机制告警恢复后我重新回看了这次故障的过程有几点值得复盘。88%这个告警阈值本身设置得偏低了等它提示我们的时候留给处理的时间窗口已经很窄。更合理的做法是把磁盘监控分成三级达到70%时通知技术负责人开始关注达到80%时通过告警群通知相关人员确认是否需要处理达到90%时作为紧急事件立即介入。还有一个经验是磁盘使用率连续多个周期持续上升的斜率趋势比单纯一个点的阈值更能预测风险。如果发现使用率每天都在稳定上涨哪怕当前只有65%也说明某个存储源在持续增长这时候就应该排查容量来源而不是干等告警。6.2 给日志空间设上限别让日志无限增长对于OpenClaw这类日志增长可预期的业务系统直接配置 logrotate 是比较成熟的方案。拿service.log举例推荐的配置是/data/applogs/*.log { daily rotate 7 compress delaycompress copytruncate missingok notifempty dateext }这个配置的含义是日志每天轮转一次保留7天的归档文件对旧日志进行压缩使用copytruncate避免影响运行中的进程文件名带日期后缀便于追溯。设置完可以手动执行一次验证配置是否正确logrotate -vf /etc/logrotate.d/openclaw-v显示详细过程-f强制执行轮转可以立刻看到效果。配置生效后日志目录的体积会被控制在一个稳定范围内不会再无限上涨。6.3 引入容量趋势预测最后提一个我常用的技巧利用简单的趋势计算来做容量预测。比如你记录了当前使用量、每天的增长率可以粗略算出剩余可用天数。公式很简单剩余可用天数 磁盘总量 × 告警阈值 - 当前用量 / 日均增长量以本次场景为例总容量100G告警阈值88%是88G当前用量62G假设日均增长2G那么剩余可用天数是(88 - 62) / 2 13天。也就是说不清理的话13天后又会回到告警线。这个计算不复杂但能帮你判断哪些问题“可以等”哪些问题“马上要处理”在容量治理中非常实用。7. 这次排障留下的几点体会事后复盘整件事我最大的感受是磁盘告警只是表象真正的问题从来不是空间不够而是“空间被什么吃掉了”以及“为什么它会持续吃”。只清日志不动代码只能换来几天的平静问题迟早会以更猛烈的姿态回来。还有一点想分享给同行遇到磁盘告警时先不要慌也不要立刻甩出各种清理命令。给自己两分钟时间把所有挂载点的使用率、inode用量、大目录排行都看一眼心里有谱之后再动手。我这次排查实际操作时间不长大部分时间花在了确认日志背后那行反复出现的异常堆栈上因为那才是值得解决的根因。关于监控阈值建议根据业务对磁盘IO的敏感度自定义不要照搬默认值。IO密集型服务在85%就可能出现性能劣化而纯存储型节点到92%可能问题也不大。适合自己业务的阈值才是好阈值。如果你的OpenClaw节点也出现了类似告警希望这篇文章里的排查路径能帮你少走几步弯路。最后一套完整的排障动作做完之后别忘了把过程和结论沉淀成文档。这次清理用到了哪些命令、定位到了什么问题、后续加了哪些防护写下来。下次再告警时你会在黄金一小时里直接命中病灶。 
长河君 · 2026/10/21 3:11:35 · 阅读 1.2k OpenClaw磁盘高位告警排查：日志清理与logrotate配置实践
【异常】OpenClaw线上服务器磁盘高位告警故障排查与解决指南凌晨两点十七分监控钉钉群突然开始震动OpenClaw线上业务节点的磁盘使用率告警被触发88%的数值已经连续挂了11个小时。这个数字一眼看上去不致命但配上“连续11小时高位运行”就很麻烦了——说明不是瞬时突发流量造成的抖动而是有什么东西一直在持续吃磁盘空间。如果放任不管大概率会从88%慢慢爬到95%以上到时候日志写不进去、临时文件落不了盘、数据库checkpoint做不了整个服务可能会以一种很难看的方式挂掉。这篇文章我把这次排查的思路和操作完整记下来从告警触发到定位元凶再到清理释放、长期治理全部走一遍。如果你手头也有类似的服务节点恰好磁盘告警了不知道从哪里下手可以参考这条路径起码能帮你少走几个弯路。1. 故障现象与风险预判1.1 告警指标解读88%和“连续11小时”意味着什么先看监控系统给出的原始告警信息磁盘使用率88%持续周期11小时告警级别为高位警告。这两个数字需要分开解读。88%本身是一个危险临界值。对于机械盘来说超过90%后文件分配会变得碎片化随机写入性能明显下降对于固态盘而言剩余空间不足10%时垃圾回收机制会频繁触发写放大效应加剧IO延迟成倍上升。对于OpenClaw这类需要持续写入业务数据的线上节点88%已经逼近了故障临界线。“连续11小时”这个时间维度更关键。如果是几分钟内的临时波动可能是某个大文件在写、某个临时任务在拉数据系统会自动释放。但连续11小时维持高位说明存在一个持续的写入源或者遗留的体积占用它不会自己消失。这个特征基本排除了瞬时流量造成的偶发告警指向的是日志积累、数据堆积、残留文件这类慢性的空间吞噬问题。1.2 磁盘高位运行的连带风险磁盘空间告急最直接的恐怖之处在于它永远不是独立故障而是一连串故障的导火索。OpenClaw节点的核心服务一旦因为磁盘满而崩掉影响面远比你想象的大。第一日志系统会先遭殃。像常用的日志采集组件在磁盘空间耗尽时无法写入缓冲区轻则丢日志重则进程直接挂掉。而日志挂了之后排障就变成了盲人摸象什么都看不到。第二数据库或消息队列的落盘操作会阻塞。以常见的中间件为例它们在写入前会预留空间来保证一致性磁盘不足时直接拒绝服务消费者和生产者的链路彻底断裂。第三自动清理机制会启动保护但保护动作本身可能引发问题。比如某些数据组件在磁盘达到阈值时会自动触发缩容或清理任务但这种被逼无奈的操作往往没有经过充分评估可能把热数据也一并清掉。我的经验是磁盘使用率跨过85%以后需要按紧急故障处理不要再等下一个监控周期去观察。接下来的一切操作都围绕“尽快安全释放空间”这个目标展开。2. 快速确认现状从告警到定位现场2.1 第一步登录节点查看整体使用率收到告警后我第一时间登录OpenClaw线上节点先用基础命令确认整体情况而不是直接漫无目的地去找大文件。df -h这条命令的输出会列出所有挂载点的使用情况。重点看根分区/因为大多数业务日志、临时文件、容器数据都落在系统盘上。我在这次排查中看到的结果是Filesystem Size Used Avail Use% Mounted on /dev/vda1 100G 88G 12G 88% /根分区总共100G已用88G剩余12G。这个剩余量撑不了太久特别是如果日志还在持续增长的话。我顺手又执行了df -i查看inode使用情况防止出现“空间还有但文件创建不了”的尴尬场景。df -i这里说明一下为什么要查inode。有些场景下磁盘空间明明还有剩余但应用就是报“No space left on device”原因就是inode用尽了。大量小文件比如临时缓存、消息队列的堆积文件会把inode耗尽。这次排查中inode使用率在合理范围内所以主线还是放在大文件占用上但我建议大家养成df -h和df -i一起看的习惯。2.2 第二步锁定空间大头所在的目录整体使用率确认后进入根目录逐层向下扫描找出哪个目录占用的空间最大。这一步的目的是缩小目标范围而不是漫无目的地到处翻找。cd / du -sh * 2/dev/null | sort -rh | head -20这里du -sh会统计每个一级目录的占用总量sort -rh按数值大小倒序排列加上2/dev/null是为了屏蔽权限不足的报错信息避免干扰视野。实际输出的前几行是48G /data 22G /var 12G /usr 5G /opt/data占了大头48G/var紧随其后22G。这个分布很典型业务数据与日志集中在/data系统日志和缓存集中在/var而/usr这类系统目录基本可以跳过因为它的体积来源于软件安装通常不会突然增长。看到这个结果排查方向就很明确了先看/data里是什么在膨胀再看/var/log是不是日志堆积。2.3 一步一步往下钻取找最大目录而不是最大文件这里要分享一个经验在大目录套小目录的层级结构里直接找“最大文件”很容易漏掉真正的元凶因为很多垃圾是分散的小文件堆积出来的。正确做法是一层层往下剖析每层都看当前级别下哪个子目录最占空间。我继续执行了du -sh /data/* 2/dev/null | sort -rh | head -10输出显示30G /data/applogs 12G /data/backup 4G /data/service排名第一的是/data/applogs30G这基本坐实了日志堆积是本次磁盘告警的元凶。到这一步大方向已经锁定剩下的就是进入日志目录看看哪种日志是“空间杀手”。3. 定位核心占用日志、容器与临时文件3.1 日志目录永远的第一怀疑对象进入/data/applogs后我按文件大小查看了最大的几个文件ls -lhS /data/applogs | head -15-S参数会按文件大小倒序排列。结果中有几个文件非常扎眼这里写一个最有代表性的-rw-r--r-- 1 app app 26G Sep 28 08:00 service.log单文件26G几乎是它一个文件把磁盘空间顶上去的。这是一个典型的业务日志文件打开一看里面全是一条错误堆栈在反复打印。这种问题比“日志太多”更棘手——它不是日志量大而是代码逻辑疑似陷入了死循环触发了异常反复写入。这里要说清楚一个处理原则单文件巨大不能直接用rm删掉就完事因为很多应用进程会保持对日志文件的文件句柄。rm之后磁盘空间不会立即释放df -h看到的还是占用状态必须要把进程重启或者用truncate清空才能让空间真正回来。这个细节对于线上节点特别重要下面实操部分我会再展开。3.2 容器相关目录overlay 层的隐形膨胀如果你在du扫描时看到/var/lib/docker或者类似的容器数据目录占了大头那优先级也很高。容器场景下的磁盘吃紧通常来自三个层面容器日志json-file驱动、镜像层缓存、以及容器内部写入但未清理的临时数据。以/var/lib/docker为例du -sh /var/lib/docker/* 2/dev/null | sort -rh | head -10如果看到containers目录很大多半是容器日志的问题如果是overlay2目录很大可能是镜像或容器可写层堆积。针对容器日志常见的处理方式是开启 log rotation日志轮转这个下面会讲到。而镜像层的清理则需要使用镜像清理命令把悬空镜像和不再使用的缓存层清掉。这次排查中/var/lib/docker占用的空间不是最大的但我在另外几次排障中遇到过它直接吃掉60%磁盘空间的情况所以这个位置一定要纳入检查范围。3.3 临时文件与缓存容易忽略的角落日志和容器之后第三个容易出问题的地方是临时目录。OpenClaw节点上有一些定时任务在处理数据如果任务异常中断临时文件可能残留下来。du -sh /tmp /var/tmp 2/dev/null这次扫描发现/tmp下有一个5G左右的任务中间文件看起来确实是某次数据处理任务中断后遗留的。这类临时文件的特点是不容易引起关注因为它们的生命周期通常是瞬时的但一旦异常就会一直躺在磁盘上。3.4 核心转储文件与dump文件再提一个新手容易忽略的核心转储文件。如果节点上的某个进程发生过崩溃系统默认会在工作目录或指定目录生成core文件。一个 core 文件的大小可能等于进程的内存占用动辄几个G甚至十几个G。find / -xdev -name core -o -name core.* 2/dev/null如果发现这类文件先确认对应进程是否还需要诊断确认不需要后即可安全删除。这次排查中没有发现 core 文件但我在之前的项目中见过 core 文件占掉20多G空间的案例值得列入常规检查。4. 清理与释放空间安全回收4.1 日志安全清理truncate 优先于 rm定位到/data/applogs/service.log是主要的空间占用者之后我开始的清理操作是有顺序的不是简单粗暴删文件。对于正在被进程持有的日志文件用truncate而不是rm是更安全的选择。truncate会把文件内容清空但保留文件本身和进程的文件句柄应用进程不会受到影响也不会出现“文件已删除但空间不释放”的悬空状态。truncate -s 0 /data/applogs/service.log执行后立刻用df -h确认Filesystem Size Used Avail Use% Mounted on /dev/vda1 100G 62G 38G 38% /使用率从88%直接落到了38%空间释放了26G。那个巨无霸日志文件被清空后磁盘压力瞬间就缓解了。但这里要提醒一句truncate只是治标如果应用还在继续往这个文件里打日志它还是会慢慢涨回去。所以清完之后一定要去看那个日志对应的服务为什么一直在输出。4.2 处理掉日志背后的代码问题我打开service.log的尾部内容确认了反复出现的异常堆栈指向的是一个数据同步模块。从日志模式上看应该是某次外部接口调用超时后模块没有做熔断而是在循环里反复重试每次都把完整的参数与堆栈写入日志。处理方案分两步第一步临时止损。调整应用日志级别将该模块的日志输出从DEBUG调整为WARN减少瞬时写入量。这一步通过配置中心下发不需要重启进程能立即生效。第二步修复逻辑。在代码层面给重试逻辑增加最大次数限制并引入指数退避策略避免在短时间内高频重试。修复完成后发版上线观察日志增长曲线是否恢复正常。这一步往往被很多人忽略但它才是本次告警真正的病根。只清日志不修复问题等于只打扫了垃圾但没有关上水龙头过两天告警又会回来。4.3 临时文件与无用备份清理日志清理完成后我又处理了之前发现的/tmp遗留临时文件以及/data/backup下的过期备份。这里说一下备份清理的原则线上备份保留周期通常按“最近7天每日完整备份 最近4周每周备份”来设计超过这个周期的历史备份可以压缩或者清除。find /data/backup -type f -mtime 30 -delete这条命令会删除30天前的备份文件。执行前我特意检查了备份任务的状态确认最新的备份产物完整存在才敢放心删除旧文件。我的一条经验是删除备份前一定先确认当前备份是可用的。否则删完旧文件才发现新备份写坏了那才是灾难。4.4 清理后的空间验证所有清理操作结束后要做一次完整的空间确认和文件系统完整性检查df -h df -i同时观察了监控面板上磁盘使用率的趋势曲线。使用率从88%开始下降后曲线逐步走平说明不仅是空间释放了日志写入量也降了下来问题确实得到了控制。对于使用 LVM 等逻辑卷管理的节点如果清理后发现根分区还是不够用还可以考虑扩展逻辑卷和文件系统。不过这次场景是空间释放足够了没有走扩容这一步。扩容属于另一套操作流程建议在明确评估存储需求后再动手不要因为一次告警就拍脑袋扩容。5. 常见问题与排查技巧实录5.1 为什么删了文件磁盘空间没有释放这个坑值得单独拿出来讲。很多人在清理空间时遇到的问题是rm删除了一个很大的日志文件然后df -h一看空间使用率压根没变。原因就是前面提到的文件句柄问题。当一个文件被进程打开后进程持有该文件的 inode即使从目录中删除了文件名inode 在进程关闭或退出前不会被释放。此时磁盘空间看起来依然是占用的。正确做法有两个使用truncate -s 0清空文件内容而不是删除文件这个对运行中的服务最友好。或者执行rm后重启持有该文件的进程让文件句柄关闭空间才会真正释放。判断哪些文件被进程持有可以用下面这条命令lsof | grep deleted如果看到大量deleted状态的文件说明这些就是用rm删掉但还没释放空间的文件找到对应进程PID后重启或让其重新加载即可。5.2 inode耗尽导致的空间假象还有一个常见的坑是“空间有剩余但无法写入文件”。如果创建的临时文件数量特别多操作系统又没有及时回收可能导致inode被全部占满。排查方法df -i如果IUse%接近100%就算df -h显示还有剩余空间应用一样会报磁盘写满错误。这时候的清理思路就不是删大文件了而是通过find / -xdev -type f | wc -l统计文件数量再定位到具体目录去批量清理无效小文件。5.3 日志轮转没有生效的原因很多系统其实配置了 logrotate但日志还是把磁盘顶爆了这个现象背后有几个常见原因。第一个是配置的轮转周期过长。比如每天轮转一次的日志如果单日生成量达到20G那它增长的上限本身就是20G设置轮转时没有评估单日日志量导致没等轮转触发磁盘已经被写满了。第二个是进程没有发送信号给应用。logrotate 轮转后通常要执行copytruncate或者发送信号让应用重新打开日志文件。如果这一步没配好应用还在往已删除的日志文件句柄里写数据轮转就形同虚设。第三个是dateext与compress的组合配置带来的空间突增。开启dateext后日志轮转会以日期命名新文件如果同时开启压缩压缩过程需要临时空间在磁盘本身就紧张时会产生额外冲击。遇到严格的低空间环境可以延迟压缩或者提前保留充足的预留空间。5.4 一条命令快速定位大目录的思路如果不想一层层du扫描可以用单条命令来一次性定位。我的习惯是du -h --max-depth2 / 2/dev/null | sort -rh | head -30这个命令能看到根目录下两层目录的空间占用排行榜基本能把98%的“空间大头”一眼找出来。它的缺点是对磁盘IO有一定压力在业务高峰期执行会短暂影响磁盘性能建议在低峰期运行。6. 容量规划与监控体系优化6.1 从一次告警到一套机制告警恢复后我重新回看了这次故障的过程有几点值得复盘。88%这个告警阈值本身设置得偏低了等它提示我们的时候留给处理的时间窗口已经很窄。更合理的做法是把磁盘监控分成三级达到70%时通知技术负责人开始关注达到80%时通过告警群通知相关人员确认是否需要处理达到90%时作为紧急事件立即介入。还有一个经验是磁盘使用率连续多个周期持续上升的斜率趋势比单纯一个点的阈值更能预测风险。如果发现使用率每天都在稳定上涨哪怕当前只有65%也说明某个存储源在持续增长这时候就应该排查容量来源而不是干等告警。6.2 给日志空间设上限别让日志无限增长对于OpenClaw这类日志增长可预期的业务系统直接配置 logrotate 是比较成熟的方案。拿service.log举例推荐的配置是/data/applogs/*.log { daily rotate 7 compress delaycompress copytruncate missingok notifempty dateext }这个配置的含义是日志每天轮转一次保留7天的归档文件对旧日志进行压缩使用copytruncate避免影响运行中的进程文件名带日期后缀便于追溯。设置完可以手动执行一次验证配置是否正确logrotate -vf /etc/logrotate.d/openclaw-v显示详细过程-f强制执行轮转可以立刻看到效果。配置生效后日志目录的体积会被控制在一个稳定范围内不会再无限上涨。6.3 引入容量趋势预测最后提一个我常用的技巧利用简单的趋势计算来做容量预测。比如你记录了当前使用量、每天的增长率可以粗略算出剩余可用天数。公式很简单剩余可用天数 磁盘总量 × 告警阈值 - 当前用量 / 日均增长量以本次场景为例总容量100G告警阈值88%是88G当前用量62G假设日均增长2G那么剩余可用天数是(88 - 62) / 2 13天。也就是说不清理的话13天后又会回到告警线。这个计算不复杂但能帮你判断哪些问题“可以等”哪些问题“马上要处理”在容量治理中非常实用。7. 这次排障留下的几点体会事后复盘整件事我最大的感受是磁盘告警只是表象真正的问题从来不是空间不够而是“空间被什么吃掉了”以及“为什么它会持续吃”。只清日志不动代码只能换来几天的平静问题迟早会以更猛烈的姿态回来。还有一点想分享给同行遇到磁盘告警时先不要慌也不要立刻甩出各种清理命令。给自己两分钟时间把所有挂载点的使用率、inode用量、大目录排行都看一眼心里有谱之后再动手。我这次排查实际操作时间不长大部分时间花在了确认日志背后那行反复出现的异常堆栈上因为那才是值得解决的根因。关于监控阈值建议根据业务对磁盘IO的敏感度自定义不要照搬默认值。IO密集型服务在85%就可能出现性能劣化而纯存储型节点到92%可能问题也不大。适合自己业务的阈值才是好阈值。如果你的OpenClaw节点也出现了类似告警希望这篇文章里的排查路径能帮你少走几步弯路。最后一套完整的排障动作做完之后别忘了把过程和结论沉淀成文档。这次清理用到了哪些命令、定位到了什么问题、后续加了哪些防护写下来。下次再告警时你会在黄金一小时里直接命中病灶。