vCenter日志满导致VAMI 5480打不开的应急清理与恢复

凌晨两点被监控电话叫醒，说 vCenter 管理界面打不开，5480 端口也不响应。爬起来 SSH 上去敲了一条df -h，/storage/log 那一行红得刺眼——100%，一个字节都不剩。这是我最近一次处理 vCenter 日志满问题的现场，也是很多管 vSphere 环境的人早晚都会碰上的场景。

vCenter 日志满这件事，说大不大，它不会让你的业务虚拟机瞬间宕机；说小也绝对不小，它会把整个管理平面按死：vpxd 起不来、VAMI 打不开、告警发不出去，连关机重启虚拟机都得绕过 vCenter 直接去 ESXi 主机上操作。更麻烦的是，如果爆掉的是数据库相关的分区，那就不是"清理几个文件"能收场的了。

这篇东西我按"先搞清楚空间被谁吃掉 → 判断哪个分区爆了 → 应急腾空间 → 把服务拉回来 → 让下次别这么快爆"这条线来写。所有命令都是我在 VCSA 6.7 和 8.0 上实际敲过的，可以直接抄作业。适合平时管 vSphere 环境、被这个问题半夜叫起来过的人看，也适合刚接手虚拟化平台、还没踩过这个坑的新人提前建立印象。

1. vCenter 的磁盘空间到底被哪些目录吃掉了

很多人第一次处理这个问题时的反应是"日志能有多大"，结果du一敲出来直接傻眼——单个 vpxd 日志几百 MB 到几 GB 都正常，环境规模大、出过故障、有服务在报错循环的，一天涨几十 GB 也不稀奇。所以动手之前，得先知道 VCSA 里哪几个目录在写东西，写的是什么。

1.1 VCSA 里必须记住的几个存储目录

VCSA 本质上是一台打包好的 Photon OS 虚拟机，磁盘按用途切成了好几个分区，每个分区职责非常明确。把下面这张表记住，定位问题时效率能高一截。

这些分区默认都在 10GB 上下（不同版本和部署规模会略有差异），整机磁盘虽然推荐 300GB 起步，但分摊下来每个分区也就那么点地方。也就是说，只要某个组件开始疯狂打日志，10GB 真的用不了多久。这一点跟很多人想象中"vCenter 磁盘给得挺大"的印象是反着的，值得提前有个数。

1.2 为什么日志会"只涨不缩"

正常情况下日志是有轮转机制的：单个文件写到一定大小或者过了一定时间，就会被压缩成 .gz，从 /storage/log 挪到 /storage/archive 去。整套机制设计得挺合理，但下面三种情况会让它失效。

第一种，某个服务进入了报错循环，日志增长速度超过了轮转速度。轮转是按周期跑的，比如每小时一次，可某个服务一分钟能写几百 MB，那轮转还没跑第二次，分区就满了。

第二种，/storage/archive 自己先满了。归档目录一满，轮转就没地方挪文件，于是新日志只能继续堆在 /storage/log，两边一起爆。

第三种，也是最容易被忽略的一种：日志文件被进程以写模式独占着，轮转时的 rename 操作失败。表现出来就是——你在 /storage/log 里ls一圈，没看到什么大文件，可df就是 100%。这种情况十有八九是"文件已经被删了，但句柄还在"，空间根本没释放。

1.3 哪几类日志最容易成为元凶

按我实际遇到的频率排个序：

• vpxd 的 vpxd-N.log：vCenter 的核心服务日志，出问题时增长最猛，几乎每次排查它都是体积榜前三。
• vsphere-ui 和 vsphere-client 的日志：Web 客户端相关，日常用得多的时候涨得也不慢。
• perfcharts 的 zip 包：统计图表相关，历史上出现过因为统计任务堆积，导致大量 zip 文件堆在这个目录的情况。
• systemd journal：系统级日志，默认不设上限的话会一直涨，属于"平时没人注意、积累起来吓一跳"的类型。
• 证书相关日志：这个要单独拎出来说。证书临期或者已经过期的时候，各个组件会反复重试连接，错误日志量会突然暴涨。很多人的"日志满"背后，真正的根因其实是证书问题，只是日志先扛不住了。

进机器后先用这两条命令看看体积排名，心里马上就有数了：

du -sh /storage/log/* | sort -h du -sh /storage/log/vmware/* | sort -h

2. 别急着删文件，先定位到底是哪个分区爆了

我见过有人一听说日志满，SSH 上去直接rm一通，结果删的是数据库目录，最后只能重装 vCenter。所以第一步永远是定位，不是清理。

2.1 VAMI 界面能告诉你什么，以及它什么时候不灵

VAMI 就是https://<你的vcenter地址>:5480，用 root 登录后进 Monitoring 里的 Disk 页面，各分区的使用率一目了然，不用碰命令行，这是最省事的入口。

但它有个前提——服务得是活的。如果爆的是 /storage/log 导致 vpxd 和 vsphere-ui 一起挂掉，5480 很可能同时打不开。这时候只能走 SSH，或者通过虚拟化平台的虚拟控制台进 DCUI。

提示：VCSA 默认不允许 root 直接 SSH 登录，需要先在 VAMI 的 Access 页面把 SSH Login 打开，或者在 DCUI 里按 F2 开启。已经开过的直接连就行。

2.2 SSH 进去之后的三板斧

三条命令，按顺序敲，基本能覆盖绝大部分情况。

# 1. 先看全局，哪个分区满了。重点看 Use% 那一列 df -h # 2. 看 /storage 下各目录的体积排名 du -sh /storage/* | sort -h # 3. 揪出单个体积异常的文件 find /storage/log -type f -size +200M -exec ls -lh {} \;

df -h告诉你"哪里满了"，du告诉你"是谁占的"，find告诉你"具体到哪个文件"。三步下来，方向就有了。

如果du的结果和df对不上——比如df说用了 10GB，du加起来才 3GB——那基本可以确认是前面说的"文件被删但句柄没释放"了。这时候补两条命令确认：

# 系统日志自己占了多少 journalctl --disk-usage # 找已删除但被进程占着的文件 lsof 2>/dev/null | grep deleted | head -20 # 万一没装 lsof，用 /proc 绕过 for p in /proc/[0-9]*; do ls -l $p/fd 2>/dev/null | grep deleted; done | head -20

2.3 一张表看清不同分区写满的症状

有时候人进不了机器（VAMI 打不开、SSH 也连不上），只能通过外部现象倒推是哪里爆了。下面这张对照表我整理过好几遍，抢修的时候挺管用。

读这张表的思路是：先用"能不能登录"区分是管理平面问题还是数据库问题，再用"图表有没有"区分是 log 还是 seat。判断准了再动手，比上来就删快得多。

3. 应急清理：哪些能删，哪些删了就得准备重装

定位清楚之后，才是清理环节。这一步的核心原则只有一条：只删可重建的东西。

3.1 可以放心删的三类东西

第一类是 /storage/archive 里的老归档。归档目录的定位就是"冷数据仓库"，超过一定天数的压缩包删掉没有任何影响，只是以后如果需要翻历史日志会查不到——但那个场景本来就很少。

第二类是 /storage/log 下已经轮转完成的 .gz 文件。这些文件已经不再被写入，删掉立竿见影。

第三类是 /storage/core 下的崩溃转储。前提是当时没有正在排查的崩溃问题，否则先把 dump 挪走再说。

# 清理 7 天前的归档 find /storage/archive -type f -name "*.gz" -mtime +7 -delete # 清理 3 天前的轮转日志 find /storage/log -type f -name "*.gz" -mtime +3 -delete # 系统日志瘦身到 200MB journalctl --vacuum-size=200M # 看一下 core 转储有什么再决定 ls -lh /storage/core

-mtime +7里的数字可以按现场情况调。实在急的话，+1也不是不行，先活下来最重要。

3.2 绝对不能手删的几样东西

• /storage/db 和 /storage/dblog 下的任何文件：这两个目录是 vPostgres 的数据目录，手删文件约等于把数据库拆了，后果是 vCenter 彻底报废，只能重装。
• /storage/seat 下的数据文件：统计和任务数据虽然没那么致命，但也不是拿来rm的，正确做法是通过界面调统计级别和保留时间来降低增长。
• 正在被进程写入的 .log：直接删不释放空间，反而会让df和du的结果对不上，干扰后续判断。

碰到第三类情况，正确姿势是让写它的进程重新打开文件：

# 先确认是谁占着这个文件 fuser -v /storage/log/vmware/vpxd/vpxd-1.log # 正确做法：重启对应服务，让它重新打开文件 service-control --restart vmware-vpxd

只有在服务本身已经挂掉、重启也来不及的极端情况下，才会考虑把文件截断成 0 字节来应急。这个操作是治标中的治标，后面一定要补上服务重启。

3.3 一次完整的应急清理序列

把上面的动作串起来，就是一套可以直接照着敲的流程。我第一次抢修的时候是一步步试出来的，后来整理成固定顺序，反复用过很多次。

# 第 1 步：记录现状，万一出问题好回溯 df -h > /tmp/disk_before.txt du -sh /storage/* | sort -h >> /tmp/disk_before.txt # 第 2 步：先清归档，这是最安全也最见效的一刀 find /storage/archive -type f -name "*.gz" -mtime +7 -delete # 第 3 步：清轮转日志 find /storage/log -type f -name "*.gz" -mtime +3 -delete # 第 4 步：系统日志瘦身 journalctl --vacuum-size=200M # 第 5 步：看 core 和 netdump ls -lh /storage/core /storage/netdump # 第 6 步：核对效果 df -h

清理顺序是有讲究的：先 archive 后 log，因为 archive 里的东西更冷，删起来更没心理负担；先 gz 后原始 log，因为 gz 已经不写了，删了不会引发任何连锁反应。每做完一步就敲一次df -h看变化，如果删了几 GB 但使用率纹丝不动，那就要停下来查句柄问题了，别继续埋头删。

正常情况下，一个 10GB 的 log 分区清理完之后能从 100% 掉到 40% 以下，archive 分区能掉到 20% 左右。如果清理后使用率只降了几个百分点，说明大头在别的地方，回去重新走一遍第 2 章的定位流程。

4. 空间腾出来之后，把服务按顺序拉起来

空间有了不代表服务会自己回来，尤其 vpxd 这种对启动顺序敏感的组件，得手动拉。

4.1 用 service-control，别用 kill

VCSA 上的服务是统一被 vmon 托管的，你手动kill -9掉一个进程，vmon 会立刻把它重新拉起来，如果根因还在，就会形成"杀了起、起了杀"的循环，状态反而更乱。正确的入口是service-control。

# 看当前所有服务的状态 service-control --status # 全部拉起来 service-control --start --all # 只想拉某一个 service-control --start vmware-vpxd # 重启某一个 service-control --restart vmware-vpxd

service-control --status的输出里，RUNNING是正常，STOPPED是停着。清理完之后建议先用--start --all走一遍，让 vmon 按它自己的依赖顺序去处理，比手动一个个起更稳。

4.2 起不来的话，日志该往哪看

如果--start之后状态还是 STOPPED，别反复点，直接去看日志。

# vpxd 的启动日志，重点看最后 200 行 tail -n 200 /storage/log/vmware/vpxd/vpxd.log # 服务托管层自己的日志，能看到启动失败的直接原因 tail -n 100 /storage/log/vmware/vmon/vmon.log # 列出所有服务的详细状态 service-control --status --all

常见的启动失败原因有两类：一类是数据库连不上（/storage/db 或者 dblog 的问题），另一类是证书问题——证书过期时 vpxd 会因为握手失败反复重试，最后启动超时。如果日志里刷的都是证书相关报错，那方向就不是清日志了，得先处理证书。

4.3 拉起来之后要确认的几件事

服务状态变成 RUNNING 只是第一步，还得实际验证功能。我一般按这几项过一遍：

• vSphere Client 能正常登录，清单树完整显示，不是只出来一半；
• 任务和事件列表能正常刷新，新任务能正常创建；
• 性能图表有数据，说明 seat 分区读写正常；
• 随便触发一个测试告警，确认告警通道是通的；
• VAMI 5480 能打开；
• 最后再敲一次df -h，如果几分钟内使用率又开始快速上涨，那说明有服务在死循环刷日志，得回到根因去查。

第六项很多人会漏，但它其实最重要——清理只是把水舀出去，如果水龙头还开着，你迟早还得再舀一次。

5. 让"临时"多撑一阵：不重启环境也能做的几个调整

标题里说的是"临时解决"，但既然已经动手了，顺手做点调整，能让下一次抢修来得晚一些，甚至不用来。

5.1 把日志级别降下来

vpxd 的日志级别是可以在配置文件里调的，配置文件一般在 /etc/vmware/vpxd/ 目录下（不同版本路径略有差异，进去ls一下就知道）。把级别从 verbose 或 trivia 降到 info，写入量能差出好几倍。改之前记得先cp一份原文件，改完不用重启整个 vCenter，重启 vpxd 本身就能生效。

不过这里要提醒一句：降级别确实省空间，但也会丢掉一部分排错细节。如果这个环境本身还在排查某个疑难问题，日志级别先别动，等排完再说。

5.2 统计级别和保留时间：seat 空间的大头

统计数据的增长是很多人没意识到的。默认的统计级别是 4，保留时间是 30 天，对一个不做精细容量分析的环境来说完全是浪费。

调整入口在 vSphere Client 里：选中 vCenter 对象，进"配置"里的"常规"，找到统计设置，把级别从 4 调到 2 甚至 1，保留时间从 30 天缩到 5 天。

注意：这个改动只影响新数据的增长速度，不会自动缩小已经存在的历史数据。想立刻看到 seat 分区变小，需要额外处理历史数据，那就不属于"临时解决"的范畴了。

5.3 一个能提前报警的 df 脚本

与其等监控打电话，不如让 vCenter 自己先喊一声。下面这个小脚本放在 VCSA 上，配合 cron 每 15 分钟跑一次，超过阈值就往系统日志里写一条。

#!/bin/sh # 保存为 /root/diskcheck.sh，chmod +x 后挂到 cron THRESHOLD=85 df -h | awk 'NR>1 {gsub("%","",$5); if ($5+0 >= '"$THRESHOLD"') print $6, $5"%"}' | \ while read mount usage; do logger -t diskcheck "分区 $mount 使用率 $usage，超过阈值" done

光写进系统日志还不够，最好能推出来。可以在这段后面接一个curl，把告警推到自己内部的告警平台或者 webhook 上。关键是阈值别设太晚，85% 就该响了，等 95% 再报，留给你的处理时间可能只有几个小时。

5.4 logrotate 参数怎么调

VCSA 内部用的是标准 logrotate 机制，配置散在 /etc/logrotate.d/ 下面，具体文件名各版本不太一样，进去ls一下就能找到。

能调的参数主要是三个：size控制单个文件多大开始轮转，rotate控制保留多少份，compress控制是否压缩。把 size 从 100M 调到 50M、rotate 从 10 降到 3、compress 打开，整体占用的下降是能明显看出来的。

改配置文件之前一定要先备份，改完可以用logrotate -d加配置文件名做一次干跑，确认语法没问题再让它真正生效。语法写错的话，轮转直接不工作，那就从"日志涨得快"变成"日志永远不轮转"了。

6. 几次抢修之后，我自己踩过的几个坑

前面讲的都是"应该怎么做"，这一节讲的是"我实际做错过什么"。这些坑文档里基本不会写，但真碰上一次就够喝一壶的。

6.1 删了文件，df 却纹丝不动

这是我第一次处理时最困惑的地方。rm掉一个 3GB 的日志，df一点变化没有。后来才明白，文件被进程打开着的时候，rm只是把目录项删掉，inode 和数据块还被进程占着，空间压根不释放。

判断方法就是前面提到的lsof | grep deleted，或者遍历 /proc 找。解决方案只有一个：让持有句柄的进程重新打开文件，也就是重启对应服务。这个坑我后来又踩过一次，那次是在 archive 分区上——文件确实删掉了，但负责轮转的进程还挂着，同样不释放。

6.2 只清了 log，忘了 archive

有一次清完 /storage/log，使用率从 100% 降到 60%，我以为搞定了。结果第二天早上又满了。回头一看 /storage/archive 是 99%——归档分区满了之后轮转无处可去，所有新日志只能留在 log 分区，等于把水舀进了一个更小的桶。

从那以后我的清理顺序固定成：先 archive，再 log，最后 journal。这个顺序保证每清一步，后续的轮转都能正常工作。

6.3 证书过期伪装成了"日志满"

这是最隐蔽的一次。客户报的是日志满，我清完第二天又满。查日志增长源头，发现是 vpxd 在反复重试某个连接，报的都是证书相关的错误。再一看证书有效期，早就过期了。

这种场景的典型特征是：清理后使用率恢复得很快，但几小时内又冲上去，而且du出来的大头集中在同一个服务的日志上。遇到这种规律性的"反复满"，就要往根因方向查了，别一直在清理层面打转。

6.4 别在业务高峰期动手

清理本身其实很快，十几分钟的事。但重启 vpxd 之后，vCenter 需要一段时间恢复，期间所有依赖它的操作都会受影响，包括自动化的运维脚本、备份任务、监控采集。

我现在做这类操作，都会先确认一下当前的业务窗口，如果实在必须在高峰期做，至少提前知会一声相关团队。另外，动手之前有条件的话用 VAMI 做一次基于文件的备份；条件不允许的，至少把要删的东西列出来确认一遍，确保每一项都可重建。这个习惯救过我一次——有一次我差点把一个看起来像日志、实际是配置备份的文件删掉。

到这里，vCenter 日志满的应急处理链路就讲完了。真要概括成一句话：定位永远在清理之前，清理永远只碰可重建的东西，服务拉起来之后一定要回头确认那个"水龙头"有没有关上。