![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/23ecd0bb80aceef37593f16dab718313.png)

我给自己定过一条线：磁盘到 85% 就得动手。那天下午打开面板，83%。

这块盘 40G，用了 31G，上面跑着几个自己的小服务、一个 mysql、一个 redis、还有一堆早就忘了为什么装的东西。这台机器已经连续跑了两百多天没重启过。

83% 这个数字很尴尬。还没到线，但也快了。摆在面前的选择就两个：扩盘，或者清理。

扩盘要钱，扩完还得自己动分区、扩文件系统，不是点一下就好。而且按这台机器的实际情况，扩了大概也治不了本。清理不要钱，但要时间，而且很可能清完两周又回来。

我选了清理。结果这件事折腾了我一个下午，最后还写出了一个 Skill。

## 一、每次清理都像考古

说实话，这不是第一次了。

以前每次磁盘紧张，我的流程都差不多：SSH 上去，`df -h` 看一眼，然后 `du -sh /*` 找大目录，再一层层往下钻。运气好的话十分钟能定位；运气不好的时候，钻到第五层发现是个不认识的目录，还得去搜它是什么、能不能删。

最烦的不是慢，是**不敢删**。

你看到一个 1.6G 的日志文件，第一反应是删了。但删之前会想：这玩意儿是不是还在被写？删了进程会不会挂？更麻烦的是那种被进程攥着句柄的文件——`rm` 一下文件名没了，空间一个字节都不释放，白忙一场。内核要等最后一个句柄关掉才肯回收。

这些年我慢慢总结出一些直觉：先看 inode 再看容量、删之前先 `lsof`、僵尸进程不能直接 kill。但这些经验只在我脑子里，换个人接手这台机器，还得从头再来一遍。

我想要的是一个东西：**我说一句"盘快满了帮我看看"，它能把从 83% 到具体文件这段路走完，顺便告诉我哪个能删、哪个碰不得。**

## 二、于是我把它写成了一个 Skill

我平时在 WorkBuddy 里干活，它支持一种叫 Skill 的东西——说白了一个目录，里面放一份说明书（`SKILL.md`）和几个脚本，AI 需要的时候自己会去读、去调。CloudQ 也是装进 WorkBuddy 用的，我就顺手给这个 Skill 起了个 `cloudq-` 前缀，标明它接的是云侧那半。

我把上面那套流程写进去了。
![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/27c045fc777c336000658f61fb0a461d.png)

骨架长这样：

```
cloudq-host-hygiene/
├── SKILL.md              说明：什么时候用、按什么顺序判断、哪些线不能越
├── references/           要查的东西：判定表、轮转配置模板、清理风险分级
├── scripts/              要算的东西：三个只读脚本
└── assets/               报告模板
```

`SKILL.md` 里最要紧的是头上那一段：

```yaml
---
name: cloudq-host-hygiene
description: 对云主机磁盘与进程卫生做分级排查——先用云侧指标圈定范围与时间窗，再用主机侧只读脚本下钻到目录级，
区分「容量耗尽 / inode 耗尽 / 已删除未释放」三类伪同类症状，找出真正的增长源并给出轮转与清理策略。
当用户提到「磁盘满了」「磁盘告警」「硬盘清理」「磁盘清理」「清理磁盘空间」「清理服务器空间」「腾空间」「盘不够用了」「扩容前评估」「inode 用尽」「日志暴涨」「僵尸进程」「机器变慢」时使用。只读诊断，清理动作一律回用户侧授权确认。
---
```

整个元数据只有 `name` 和 `description` 两个字段。名字是标识，`description` 是**唯一决定它什么时候被触发的字段**——所以它不能写成产品介绍，得说清三件事：做什么、什么时候用、边界在哪。

最后那句就是边界，而且必须写：触发词里有一半是"帮我清理硬盘"这类**行动意图**，不写死的话，模型很容易把"用户要我清理"读成"用户授权我删除"。

拆的时候只有一条原则：**能算出确切答案的，不要让 AI 心算。** 磁盘占用是算术题，交给脚本；判断"这属于哪一类问题"，交给模型。

这里最关键的是三分类。

同样是 83%，背后可能是三件完全不同的事：

- **inode 满了**。容量还有，但文件数量到顶了。删大文件没用，得减少文件数。
- **文件被删了但空间没释放**。进程还攥着句柄，`rm` 完全无效，得让进程松手。
- **真的在涨**。那就得找到那个正在长大的东西，配轮转。

这三件事在监控面板上长得一模一样。判断顺序错了，处置就全错。
![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/803486628cf011896573ab9ed15663b0.png)

落到命令上，其实就是三步：

```bash
# ① 先看 inode：容量还有，也可能已经耗尽
df -i

# ② 再对账：df 与 du 差得远，说明有文件被删了但没释放
df -Pk / | awk 'NR==2{print $3}'     # df 已用（KB）
du -sxk / | awk '{print $1}'          # du 合计（KB）

# ③ 最后才找增长源：同一目录隔一段时间采两次，看差值
```

所以我在说明书里写了条死规矩：**先看 inode，再核对 df 和 du 对不对得上，最后才谈增长源。**

另外几条是从踩过的坑里抄下来的：删之前必须查 `lsof`；要找"增长最快"的而不是"占用最大"的；日志类问题必须落到轮转配置，只删不配，两周后原样回来；僵尸进程本身 kill 不掉，要处理它的父进程。


## 三、它给我的清理建议

诊断跑完之后，它给我一张单子：先列"不能动的"，再列"能动的"，每条都带风险级别。

第一版单子里，"不能动"那栏写着：**三个 swap 文件，合计 9G，L3，不可清理。** 理由也对得上——这台机器内存只有 1.8G，当时可用只剩 388M，swap 已经吃进去 575M，动它很可能当场 OOM。

我本来打算就这么接受了。但顺手多敲了一句 `swapon --show`：

```
NAME      TYPE SIZE  USED PRIO
/www/swap file   1G 567.9M   -2
```

只有 1G 在跑。另外两个呢？

```
-rw------- 1 root root 4.0G Jan 29  2026 /swapfile
-rw------- 1 root root 4.0G Feb  1  2026 /swapfile2
```

`/etc/fstab` 里也只有一个 swap 条目，就是 `/www/swap`。这两个 4G 的文件是今年 1 月底先后建的，当时大概手动 `swapon` 过；机器两百多天前重启之后，因为 fstab 里没有它们，就再没被启用过。

**躺在那儿占着 8.2G，一天活都没干过。**

这是我第一次真切感觉到这类工具的边界：它能看见"盘上有 9G 的 swap 文件"，看不见"这 9G 里只有 1G 是活的"。它给的是保守判断——对不可回滚的操作宁严勿松，这个方向没错；但保守不等于准确，最后一层还得人去核。

第二处错在 locale。单子里记的是"`locale-archive` 213 MB × 2，重复文件"，还列进了可回收项。实际是这样：

```
135014 -rw-r--r--. 2 root root 223542144  locale-archive
135014 -rw-r--r--. 2 root root 223542144  locale-archive.real
```

同一个 inode，`links=2`，md5 一样——**硬链接**，两个名字指着同一份数据。删掉一个，链接数从 2 变 1，磁盘一个字节都不会少。

所以真正能动的只有这几项：

| 项 | 大小 | 能不能真回收 |
|---|---|---|
| `/swapfile` + `/swapfile2`（未启用） | 8.2G | 删即释放 |
| `/www/server/cron/*.log` | 1.6G | 截断即释放 |
| 站点访问日志 263M + 错误日志 145M | 408M | 配轮转后释放 |
| `/www/swap`（启用中） | 1G | 动了 OOM |
| `locale-archive.real` | — | 硬链接，删了不省空间 |

那个 1.6G 的 cron 日志，它判 L2：

```bash
# 是 truncate，不是 rm
# 保留文件本身和 -rw------- root 权限，cron 下次 >> 追加照常写得进去
truncate -s 0 /www/server/cron/<hash>.log
```

这里它给的理由原本是"rm 只删目录项，进程还开着句柄，内核不回收空间"。我查了 `lsof /www/server/cron/`，**没有任何进程持有这些文件**——cron 是 `*/10` 的短进程，写完就退出。所以这条理由在这个场景下不成立，`rm` 也能释放空间。选 `truncate` 的真实理由是另一件事：**保住 inode 和权限**。`rm` 之后 cron 下次写入会重建一个新文件，属主权限都得重配。

动作给对了，理由却是套模板来的。这种事只能靠人看一眼。

站点日志那边，它建议配 logrotate，而且特别提醒 nginx 要用 `USR1` 信号重开，不能用 `copytruncate`，否则会在复制和清空之间丢掉写入：

```bash
# /etc/logrotate.d/wwwlogs
/www/wwwlogs/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -f /www/server/nginx/logs/nginx.pid ] && \
            kill -USR1 $(cat /www/server/nginx/logs/nginx.pid)
    endscript
}
```

`delaycompress` 这个参数后面会用到——它让最近一份归档先不压缩，正是"轮转完了盘没变小"的由来。

cron 那边不一样，它写完就退，不认信号，所以用的是 `copytruncate`。

它把动作分了四级：L0 只读、L1 低风险、L2 中高风险、L3 禁止。**只读的 L0 可以直接跑，L1 和 L2 必须人点头，L3 连命令都不给。** 每条建议都要写全四项——命令、影响面、回滚方式、前置确认项，缺一项算不合格。

后来我拿信通院那份《云上 Agent 基准度量模型》对了一眼。里面有一项指标叫「人类批准依赖度」，说的是按操作的风险等级决定哪些必须人来拍板——我把这个思路落成了 L0 到 L3，写进 `references/`，而不是让模型临场判断。

那两个僵尸 swap 我这次没删。8.2G 摆在那儿很诱人，但后来翻 `dmesg`，这台机器有 **347 次 OOM 记录**——内存压力是真的，删之前我想再确认一遍它们确实从没被用过。

## 四、清掉 1.6G 之后，我发现真正的问题不是磁盘

单子里风险可控、又不用重启服务的只有两件，我就先做这两件。

先截断那个 1.6G 的 cron 日志：

```bash
truncate -s 0 /www/server/cron/<hash>.log
```

秒回 1.6G。

再强制跑一次站点日志轮转：

```bash
logrotate -f /etc/logrotate.d/wwwlogs
```

跑完所有 `*.log` 变成了 `*.log.1`，nginx 收到 `USR1`，自己重开了一个新文件。

结果：**31G 变 30G，可用从 6.5G 涨到 8.1G，使用率 83% 降到 79%。** nginx 进程号前后都是 `4183203`，没重启，本地请求回来 200，11.7 毫秒。

![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/a89b538af984c9109c34023970933700.png)

**这台机器的病根不在磁盘。**

1.8G 内存，上面跑着 nodejs、mysql、redis、一个面板、还有几个常驻服务。可用内存一直在 400M 上下打转，swap 吃掉半 G 多——那 9G 的 swap 文件不是浪费，是它在硬撑。

磁盘 83% 只是它喘不上气的症状之一。如果当时图省事扩了盘，钱花了，内存的问题一个没解决，盘照样继续涨。

所以最后我没扩盘。清出来的这点空间够再撑一阵，但真正要办的是升内存。
![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/e4ae9f3c3805efa0c992bcc01c8e8e63.png)

## 五、云上那一半，得靠 CloudQ 看

写到这里，得说一下 CloudQ——毕竟这个 Skill 是按它的场景做的。

CloudQ 是腾讯云做的一个云上运维 Agent，简单理解：**不用登控制台，在对话框里说一句话，它就能帮你查云上的事。** 资源查询、巡检、诊断、成本、容量，这些活儿都收在同一个入口里。

我这次的用法很简单：把它当成"云上的眼睛"。因为主机侧和云侧看到的，根本不是一回事。

我 SSH 进去，能看到每个目录、每个文件、谁在写、inode 用了多少。但有几件事，在机器里怎么查都查不到。

**第一件，这台机器到底是什么。**

我只知道它有块 40G 的盘、用了 83%。但我不知道它是 ESSD 还是高效云盘、有没有加密、实例什么规格、什么时候到期——而这些恰恰决定了"该不该扩容"这个问题。

查完才知道：`cloud_essd_entry`，40G，未加密，`ecs.e-c1m1.large`——2 核 2G 的经济型实例，2027 年 2 月到期。这几个数字把整件事翻过来了。如果它是 8G 内存配一块高效云盘，那该扩就扩；可它是台 2G 内存的经济型机器，扩盘等于给一个饿肚子的人换个大碗。

**第二件，谁能连进来。**

`ss -lntp` 能看到本机监听了什么，但看不到"外面谁能连进来"。这两件事差得很远。

云侧的安全组里躺着 27 条入口规则，其中 22 条对 `0.0.0.0/0` 开放——宝塔面板的 36051 在里面，还有几个端口我早忘了当初为什么开。MySQL 的 3306 原来也在，那条我当天就改成了只允许内网，宝塔那个还开着。

主机侧一切正常，云侧一堆门没关。这种反差，只有把两边数据摆在一起才看得出来。
![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/0b9d4978f82b5a6f337783f38f7e98f5.png)

**第三件，谁动过这台机器。**

这是主机侧最彻底的盲区。

`/etc/hosts` 这个文件的修改时间，我看过不止一个版本。但机器只能告诉我"什么时候变的"，告诉不了我"谁变的、从哪变的"——`systemctl is-active auditd` 返回的是 `inactive`，`/var/log/audit` 是空的。文件被谁改过，一行记录都没有。

云侧答得了。这台实例相关的操作，最近 30 天一共 5 条记录，每条都带着时间、操作者、来源 IP、改了哪个参数。账号级的登录事件要另查——登录不属地，得去全局区域的操作审计里找。两边拼起来，能看到我自己某天凌晨的一次操作：00:37 登录，看了一眼工单页，00:40 加了条临时端口规则，00:54 又删掉。连我自己都忘了，记录还在。
![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/c5fab0d5e5e6f0c6e8a9b19e88018f14.png)

---

这三个问题，云侧一次就能答完。而 CloudQ 做的，就是把这类东西收到一个地方。

它的底座叫**全景图谱**，把资源拓扑、调用链路、流量、告警事件、云资源变更审计、APM 六类数据都纳进去，节点之间能互相走通。从一台实例出发，可以顺着走到它挂的盘、它所属的安全组、最近谁动过它、上游还有谁在调它——中间不用换页面。

对我来说，最实在的是省掉了"登控制台、点菜单、找页面"这一整套动作。以前查一台实例的规格，得点进四五个页面；现在一句话的事。

还有一点我挺认可：它默认给的是**只读权限**——智能顾问之外，其他云产品一律只读，涉及变更得你自己去点。运维最怕的就是工具替你想多了，尤其在凌晨三点脑子不清醒的时候。
![image.png](https://developer.qcloudimg.com/http-save/yehe-10086078/53255421c7c8bdbb4500a3992b73a612.png)
需要说明一句：我这台机器在阿里云，上面那些云侧数据是我用阿里云 OpenAPI 查出来的。CloudQ 是腾讯云的产品，在腾讯云侧提供的是同一类能力，只是收在一个对话入口和一张图里（阿里云也在它的多云纳管列表里，官方说法是相关能力陆续开放）。我仍把它放进这条链路，是因为分工的逻辑是通的：**云侧接口各家不同，但"云上看全局、机器里看细节"这件事不变。**

所以这两个东西是互补的：

**CloudQ 负责在云上看清这台机器怎么了，Skill 负责钻进机器里看细节。** 一个给视野，一个给证据。

## 省下的空间，其实不是重点

这次折腾完，我最大的收获不是省下来的空间。

是以后这台机器再告警，我不用再从 `df` 开始一层层翻了。一句话进去，它会按固定的顺序走完：先看 inode，再核对容量，再找增长源，最后告诉我哪个能动、哪个不能动、动了会怎样。

那套"先看什么、后看什么、什么不能碰"的判断，以前只在我脑子里。现在我把它写下来了。

写下来这件事本身，可能比省下的空间值钱。



这块盘 40G，用了 31G，上面跑着几个自己的小服务、一个 mysql、一个 redis、还有一堆早就忘了为什么装的东西。这台机器已经连续跑了两百多天没重启过。

那台40G云服务器服务器硬盘空间告警之后，我给它写了个 Skill

把一个磁盘清理决策写成 Skill：从 83% 走到具体文件，且每一步都可被检验。

项目经理

人工智能

磁盘83%预警触发清理实战：从inode排查、df/du对账到定位未启用swap文件，一套云主机卫生Skill将运维经验固化为L0-L3分级处置流程，配合云侧审计洞察，揭示真正瓶颈是2G内存而非磁盘。

代码解释

日志文件

文件系统

智能顾问

WorkBuddy 

云主机

服务器

多云

CloudQ

Nginx

Redis

MySQL

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

那台40G云服务器服务器硬盘空间告警之后，我给它写了个 Skill-腾讯云开发者社区-腾讯云

那台40G云服务器服务器硬盘空间告警之后，我给它写了个 Skill

那台40G云服务器服务器硬盘空间告警之后，我给它写了个 Skill

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐