凌晨两点被监控电话叫醒说 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 虚拟机磁盘按用途切成了好几个分区每个分区职责非常明确。把下面这张表记住定位问题时效率能高一截。目录装的东西写满后的典型后果/storage/log所有组件的运行日志/var/log 是它的软链接vpxd 可能启动失败VAMI 5480 打不开/storage/archive轮转归档后的老日志logrotate 挪不动文件新日志只能堆在 log 分区/storage/dbvPostgres 主数据目录vpxd 连不上库整个 vCenter 服务全线挂掉/storage/dblogPostgres 的 WAL 预写日志与 db 同样致命写不进去就是服务级故障/storage/seat统计、事件、任务数据性能图表断掉任务和事件列表写不进去/storage/core进程崩溃时产生的核心转储崩溃信息写不下排查故障缺材料/storage/netdump网络抓包转储抓包功能失效/storage/updatemgr升级包缓存打补丁更新失败/系统根分区各种想不到的连带故障SSH 都可能登不上这些分区默认都在 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.logvCenter 的核心服务日志出问题时增长最猛几乎每次排查它都是体积榜前三。vsphere-ui 和 vsphere-client 的日志Web 客户端相关日常用得多的时候涨得也不慢。perfcharts 的 zip 包统计图表相关历史上出现过因为统计任务堆积导致大量 zip 文件堆在这个目录的情况。systemd journal系统级日志默认不设上限的话会一直涨属于平时没人注意、积累起来吓一跳的类型。证书相关日志这个要单独拎出来说。证书临期或者已经过期的时候各个组件会反复重试连接错误日志量会突然暴涨。很多人的日志满背后真正的根因其实是证书问题只是日志先扛不住了。进机器后先用这两条命令看看体积排名心里马上就有数了du -sh /storage/log/* | sort -h du -sh /storage/log/vmware/* | sort -h2. 别急着删文件先定位到底是哪个分区爆了我见过有人一听说日志满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说用了 10GBdu加起来才 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 -202.3 一张表看清不同分区写满的症状有时候人进不了机器VAMI 打不开、SSH 也连不上只能通过外部现象倒推是哪里爆了。下面这张对照表我整理过好几遍抢修的时候挺管用。观察到的现象大概率是哪个分区紧迫程度vSphere Client 登录报错5480 打不开/storage/log高客户端能登录但性能图表全是空白/storage/seat中所有 vCenter 服务都起不来service-control报数据库错误/storage/db 或 /storage/dblog极高清理完 log 分区几小时后又满了/storage/archive 满了导致轮转失效高SSH 登录异常、各种命令报奇怪的错/ 根分区高更新补丁时卡在下载阶段/storage/updatemgr低读这张表的思路是先用能不能登录区分是管理平面问题还是数据库问题再用图表有没有区分是 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-size200M # 看一下 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-size200M # 第 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别用 killVCSA 上的服务是统一被 vmon 托管的你手动kill -9掉一个进程vmon 会立刻把它重新拉起来如果根因还在就会形成杀了起、起了杀的循环状态反而更乱。正确的入口是service-control。# 看当前所有服务的状态 service-control --status # 全部拉起来 service-control --start --all # 只想拉某一个 service-control --start vmware-vpxd # 重启某一个 service-control --restart vmware-vpxdservice-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.shchmod x 后挂到 cron THRESHOLD85 df -h | awk NR1 {gsub(%,,$5); if ($50 $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 日志满的应急处理链路就讲完了。真要概括成一句话定位永远在清理之前清理永远只碰可重建的东西服务拉起来之后一定要回头确认那个水龙头有没有关上。