接手过不少 vCenter 半死不活的现场真正因为证书链断了、数据库崩了导致整台设备趴下的次数其实远没有“磁盘写满”来得多。而所有磁盘写满里/storage/log 被日志撑爆又是绝对的头号选手。日志满这件事最阴的地方在于它不会一上来就把 vCenter 打死——先是任务提交变慢接着 vSphere Client 登录转圈再然后是 VAMI 打不开、服务起不来、证书自动续期失败等你发现的时候已经是一堆故障叠在一起了。这篇东西不讲大道理就讲我在现场怎么在十分钟内把空间腾出来、怎么让腾出来的空间撑得久一点、以及哪些操作看着解气实际上会把事情搞得更糟。适合手里正捏着一台告警的 vCenter、又不想在业务时间重启整台设备的运维同行也适合刚接手虚拟化平台、还没遇到过这种场面的朋友。1. vCenter 日志满的真实表现与根因拆解1.1 故障现场长什么样从“还能登”到“登不上”的四个阶段我见过的 vCenter 因为日志满引发的故障基本都会沿着一条比较固定的路径往下滑识别出自己在第几阶段直接决定了你能不能只清日志就把事情压下去。第一阶段是“感知迟钝期”。这个阶段你几乎察觉不到异常只有 VAMI 首页的存储用量卡片开始泛黄/storage/log 的使用率爬到 80% 以上。此时任务还能提交虚拟机还能正常开机唯一的变化是 vSphere Client 里某些页面加载会顿一下——因为 vpxd 在往已经很大的日志文件里追加内容写入变慢间接拖累了响应。这个阶段动手成本最低可惜绝大多数人都是被后面的阶段叫醒的。第二阶段是“功能局部失灵期”。使用率过了 95%一些依赖写日志的服务开始报错。表现是任务提交成功但卡在“进行中”不动告警里开始出现“无法完成操作”之类的模糊提示证书自动续期任务静默失败。这时候你去 VAMI 看服务列表里会有一两个显示为黄色或红色但点“启动”又起不来。第三阶段是“服务连环倒”。100% 满了之后服务写不了日志就直接退出而 vCenter 的很多服务是互相依赖的vpxd 依赖 vpostgresvsphere-ui 依赖 vpxdvmon 又在看着所有服务的状态试图拉起来。这时候你打开 VAMI 会得到 503SSH 进去执行 service-control 也会报错因为连 service-control 自己都要往 /var/log 里写东西——而 /var/log 在 VCSA 里就是 /storage/log 的软链。第四阶段是“恢复困难期”。这个阶段最难受的其实不是空间而是空间腾出来之后服务依然起不来配置写到一半被中断、数据库的 WAL 没落盘、证书续期写坏了文件。所以我自己的原则是只要看到使用率超过 90%不管业务有没有反馈当天必须处理。1.2 /storage 分区地图哪些目录才是日志的真正大户很多人第一次 SSH 进 VCSA看到 /storage 下面一堆目录会有点懵。先把这张地图记住后面定位问题会快很多。路径主要内容能不能清/storage/log所有组件日志/var/log 的软链目标能清优先清这里/storage/core服务崩溃产生的 core dump确认无工单后可清/storage/dbvpostgres 数据目录绝对不能动/storage/seat遥测与统计相关数据不要手删走配置关闭/storage/archive归档类数据谨慎先确认用途/storage/imagebuilder镜像配置文件不要动/storage/updatemgr补丁与更新缓存可清缓存不要删目录/storage/autodeploy自动部署配置不要动/storage/log 的默认容量跟部署规模挂钩小规模环境通常在 10GB 上下中大规模一般落在 15GB 到 20GB 这个区间具体数值以 df 输出为准别凭记忆判断。真正容易出事的是很多人以为日志分区 20GB 很大但 vpxd 一个组件在异常状态下一天写掉几个 GB 是常事。在这个分区里按体量排下来通常是这么个顺序vpxd 目录第一vpxd.log 加上一堆归档异常时能到几十 GBvpxd-profiler 之类的剖析输出第二单文件动辄几个 GB而且是纯性能剖析数据没有任何排查价值vpostgresql 和 vmdird 第三平时不大一旦数据库或认证链路有问题就会暴涨vsphere-ui、eam、rhttpproxy 这些属于“平时安静、出事就疯”的类型。还有两个不常被想起来的地方一个是 /storage/core 里的 core dump服务崩溃时会产生单个文件可能就有好几个 GB而且崩溃往往是循环发生的一次故障下来能攒出十几个另一个是 systemd 的 journal位于 /var/log/journal默认会自己控制大小但在异常刷屏的场景下同样能吃掉几个 GB。1.3 五类高频根因为什么日志会在几天内涨满清日志只是止血搞清楚“为什么涨”才能决定清完之后要不要立刻做别的动作。我按遇到频率排了个序。**第一类vpxd 陷入错误循环。**这是最常见的。vpxd 在向某个外部依赖数据库、SSO、AD、其他 vCenter 节点发起请求失败后会以很高的频率重试并记录错误每条错误都是一段带堆栈的文本。我见过最夸张的一次vpxd.log 每小时涨 1.5GB原因只是 SSO 那边某个服务的连接被防火墙策略挡掉了。判断方法很简单tail 一下 vpxd.log如果满屏都是同一条错误基本就是这个原因。**第二类日志轮转本身失效。**这是个很隐蔽的正反馈循环轮转需要创建新文件、需要重命名旧文件而这些都是写操作磁盘接近满的时候轮转会失败于是组件继续往同一个文件里追加文件越来越大轮转更不可能成功。所以你会看到一个几十 GB 的 vpxd.log旁边一个归档文件都没有——这本身就是“轮转早就挂了”的信号。**第三类服务崩溃刷 core dump。**某个组件因为内存或依赖问题反复崩溃每次崩溃都往 /storage/core 里丢一个体积不小的核心转储文件。这类故障的特点是空间掉得特别快而且 du 出来你会发现在 /storage/log 里找不到大头问题在 /storage/core。**第四类第三方插件或扩展在报错。**比如某些备份软件、监控代理、存储插件装到 vCenter 上它们自己的日志也在往 /storage/log 里写。这类日志通常位于 /storage/log/vmware/ 下以插件命名的目录或者干脆在 /var/log 根下。清理的时候顺手看一眼别只盯着 VMware 自己的目录。**第五类认证与证书相关的重试风暴。**这一类我要单独展开说因为这个坑我踩过。1.4 借“证书过期”说个连锁反应vCenter 的证书过期是个很典型的多米诺证书一过期所有依赖证书的组件间通信开始失败每个失败都会被各组件记一条错误组件发现失败后会重试重试有间隔但往往很短于是日志以异常的速度增长把 /storage/log 撑满空间满了之后证书自动续期任务因为写不了文件而失败证书续不回来错误继续刷日志继续涨。我在一个客户现场就遇到过这套组合拳早上八点开始有人反馈登录慢十点 vSphere Client 打不开中午我拿到现场vpxd.log 已经 34GB/storage/log 显示 100%VAMI 的 503。attr 顺序很清楚——先把空间腾出来再处理证书顺序反了会白忙一场。这里有个经验值得记下来**当你看到日志里大量出现认证、连接、证书之类的关键字并且频率高得不正常先别急着删日志先记下错误原文和时间戳。**因为清完日志再重启服务这些证据就没了而你马上就要用它们去定位根因。我一般会在清理前做一件事mkdir -p /root/incident-$(date %Y%m%d) grep -i -m 200 -E cert|ssl|auth|refused|timeout /storage/log/vmware/vpxd/vpxd.log \ /root/incident-$(date %Y%m%d)/vpxd-sample.log tail -n 500 /storage/log/vmware/vpxd/vpxd.log \ /root/incident-$(date %Y%m%d)/vpxd-tail.log这两条命令只花几秒钟占用几十 MB但保留了最关键的信息。等空间腾出来之后你就可以拿着这份样本去对着时间线看比在几十 GB 的日志里翻要省事太多。注意如果你正在跟厂商开支持工单/storage/core 里的核心转储文件先别删哪怕它很大。删掉之后再想复现成本会高得多。2. 救火前的准备入口、备份与操作边界2.1 三条登录入口与各自的适用场景日志满的时候登录方式本身就是个问题不同阶段能用的入口不一样提前知道有哪几条路现场会从容很多。**第一条是 SSH。**正常情况下用 root 账号 SSH 到 vCenter 的 IP进去是 appliancesh受限的命令行外壳需要再敲shell才能进 Bash。空间没满的时候这条路最顺。但如果已经到第三阶段SSH 可能连不上因为 sshd 也需要写日志。**第二条是 VAMI。**浏览器访问https://vcenter-ip:5480用 root 登录这里是图形化界面能做服务启停、能看存储用量、能配置 syslog 和备份。它的优势是不依赖 SSH 通道劣势是空间满的情况下它自己也起不来。**第三条是 DCUI也是最后的底牌。**在 vSphere Client 或 ESXi 主机客户端里找到 vCenter 这台虚拟机的控制台直接打开看到的是一个黑底菜单。里面有个 Troubleshooting Options故障排除选项可以临时启用 SSH 和启用 Bash Shell。这条路的好处是完全绕开 guest OS 里的服务图形控制台是 ESXi 层提供的只要虚拟机能开机就能用。我的实际操作顺序是先试 SSH连不上走 DCUI 打开 SSH 和 Bash再用 SSH 进去干活。DCUI 里还有个 Restart Management Agents 的选项一般不用碰因为 VCSA 不是 ESXi那个选项在里面意义有限别乱按。2.2 动手前必须做的三件小事日志清理由看起来是“删东西”但职业习惯要求你在动手前做几个确认动作这几个动作总共花不到两分钟。**第一件确认这台设备最近有没有被人改过。**比如是不是刚做过升级、刚换过证书、刚装过插件。这些信息决定了你后面是只清日志还是要顺手处理别的。如果团队里有变更记录翻一眼没有的话看几个文件的修改时间也能猜个八九不离十ls -l --time-stylelong-iso /etc/vmware-vpx/vpxd.cfg ls -lt --time-stylelong-iso /storage/log/vmware/ | head**第二件确认当前的空间分布和 inode 使用情况。**很多人只看 df -h不看 inode。inode 耗尽的情况下df -h 显示还有空间但任何写操作都会报 “No space left on device”这是另外一个完全不同的排查方向先排除掉能省很多时间。df -h df -i**第三件把要改的配置文件备份掉。**如果你打算调整日志级别或者其他参数先cp一份带日期的备份。这是纪律不是可选项。cp -a /etc/vmware-vpx/vpxd.cfg /etc/vmware-vpx/vpxd.cfg.bak-$(date %Y%m%d%H%M)提示日志满的时候不要创建虚拟机快照。虽然快照本身落在存储上看似不占 guest 空间但快照会冻结瞬时 I/O、产生 Delta 文件在你还没搞清楚状况之前增加一个变量得不偿失。清理日志这种操作不动配置风险本来就是可控的。2.3 什么能删、什么打死不能删这一节是我认为最该先看的部分。现场慌乱的时候最容易发生的就是rm -rf /storage/log/*这类操作看着解气后果是某些服务因为找不到预期的日志目录而启动失败而且不会自动重建。**可以放心处理的**已经轮转出来的归档文件名字里带.gz、.old、.1这类后缀的vpxd-profiler 之类的性能剖析输出/storage/core 里超过一定天数的核心转储前提是没有正在跟进的工单/storage/updatemgr 里的旧补丁缓存。**只能截断不能删除的**所有正在被进程写入的当前日志文件比如 vpxd.log、vpostgresql 的当前日志。对这类文件删除不会释放空间下面会详细讲必须用截断的方式清零。打死不能动的/storage/db 下的任何内容尤其是 vpostgres 的数据目录和 WAL 文件动一下数据库可能就废了/etc 下的任何配置文件/storage/seat、/storage/imagebuilder、/storage/autodeploy 这些目录本身。**判断标准很简单**如果这个路径是某个服务启动参数里指定的目录那它就应该保留如果只是历史产物那就可以清。拿不准的时候只清归档文件和 profiler这两个基本不会出问题。3. 临时止血命令行腾空间的完整实操3.1 第一步用 vdf、df、du 三层定位到具体目录定位这件事要有顺序从粗到细不要一上来就 find 整个文件系统那样又慢又费 IO。**第一层看分区级使用率。**VCSA 里有个挺好用的命令叫vdf -h它输出的视角和 VAMI、DCUI 看到的更接近能直接告诉你哪个分区该管。当然df -h也可以用两个一起看更保险。vdf -h df -h df -i**第二层看一级目录的体量。**这一步能让你三秒钟内知道问题在 /storage/log 还是在 /storage/core。du -sh /storage/* 2/dev/null | sort -h**第三层钻到具体组件。**如果确认是 log 分区继续往下拆du -sh /storage/log/vmware/* 2/dev/null | sort -h du -sh /var/log/* 2/dev/null | sort -h | tail -20到这一层基本就水落石出了。如果还是找不到大头说明可能是大量中小文件堆积或者空间被“已删除但被占用”的文件吃掉了这时候改用查找大文件的思路find /storage/log -xdev -type f -size 500M -printf %s\t%p\n 2/dev/null \ | sort -n | awk {printf %.1f MB\t%s\n, $1/1048576, $2}这条命令会列出 /storage/log 下所有超过 500MB 的文件从小到大排序最后几行就是你要处理的。用-xdev是为了不跨分区避免把整个存储都扫一遍。3.2 第二步截断而不是删除以及为什么这是全文最重要的一个技术点。在 Linux 里删除一个文件只是把目录项摘掉如果还有进程持有这个文件的句柄文件的数据块并不会被释放df看到的可用空间也不会变。日志文件恰恰是被服务长期打开着的所以你rm掉一个 20GB 的 vpxd.logdf可能纹丝不动——空间要等到 vpxd 重启、句柄关闭之后才会真正释放。正确做法是截断也就是把文件内容清零但保留文件本身和它的 inode# 方式一最简单重定向一个空内容进去 : /storage/log/vmware/vpxd/vpxd.log # 方式二语义更明确 truncate -s 0 /storage/log/vmware/vpxd/vpxd.log截断是立即生效的持有句柄的进程不会报错它会继续往后写偏移量从新文件末尾接着算不影响服务运行。这是日志满场景下最优雅的止血方式。**批量处理的时候要注意顺序。**先清归档那些不需要保留句柄的再截断当前日志。归档文件用 rm 删是安全的find /storage/log/vmware -type f \( -name *.gz -o -name *.old -o -name *.1 \) -mtime 1 -print先把-print跑一遍看清单确认没有误伤再换成-delete执行。这个习惯我建议一直保留尤其是命令里带通配符的时候。注意不要一次性截断所有组件的当前日志。有些服务在日志文件被外部修改时会重新打开文件极端情况下可能因为短暂的竞争条件产生报错。稳妥的做法是逐个组件处理处理完一个df -h看一眼。3.3 第三步清理 core dump、profiler 与历史归档这三类东西是清空间的“高性价比目标”因为它们体积大、没有保留价值、删除风险低。core dump在 /storage/core 下通常是服务崩溃时生成的二进制文件。清理前先看体积和时间分布du -sh /storage/core find /storage/core -type f -mtime 7 -printf %TY-%Tm-%Td %10s %p\n 2/dev/null | sort | tail -20确认清单合理之后再按时间清理比如保留最近七天find /storage/core -type f -mtime 7 -delete如果 /storage/core 里有正在被写入的 core 文件也就是服务还在持续崩溃光删是没用的得先解决崩溃本身。判断方法看文件名的时间戳是不是“刚刚”隔一分钟再看一次还在不在。profiler 输出是我个人最推荐优先清理的东西。它位于 vpxd 的日志目录里文件名一般以 profiler 开头动辄几个 GB而且除了厂商深度性能分析场景日常运维完全用不到find /storage/log/vmware/vpxd -maxdepth 1 -type f -name *profiler* -printf %s\t%p\n 2/dev/null | sort -n确认之后直接删。不同版本里这个文件的命名可能略有差异以实际 find 结果为准别看名字猜。历史归档就是前面提到的 .gz、.old 这批清的时候可以按天粒度保留比如只留最近两天。3.4 第四步给 systemd journal 和系统日志瘦身这一步经常被忽略但在刷屏场景下收益不小。VCSA 基于 systemdsystemd-journald 会把内核和服务日志写到 /var/log/journal 里默认能吃几个 GB。journalctl --disk-usage journalctl --vacuum-size200M journalctl --vacuum-time7d--vacuum-size是压到指定大小以下--vacuum-time是按时间清理两个可以配合用。执行完之后再journalctl --disk-usage确认一下。如果你希望这个限制长期生效改配置文件vi /etc/systemd/journald.conf把#SystemMaxUse那一行的注释去掉改成SystemMaxUse200M然后重启 journaldsystemctl restart systemd-journald这个改动是“临时手段里带一点长效”的性质我一般会顺手做掉因为 journal 在故障期间刷屏特别厉害200MB 的上限既够用又不会失控。系统侧的 /var/log/messages、/var/log/secure 这类文件走的是 logrotate配置在 /etc/logrotate.d/ 下面正常情况下不用改但如果发现有单个文件特别大可以临时手动轮转一次logrotate -f /etc/logrotate.conf3.5 第五步服务重启与空间回收验证清完之后有一件事必须确认**被删掉但还被句柄持有的文件有没有需要重启服务才能释放。**检查方法lsof L1 2/dev/null | head -30这条命令列出所有“链接数为 0 但仍有进程打开”的文件也就是已删除未释放的。如果输出里出现大文件并且关联的是 vpxd、vpostgres 这类关键服务那部分空间就得靠重启服务才能拿回来。重启单个服务是安全的用 service-controlservice-control --status --all service-control --restart vmware-vpxd--status先看一眼全局确认哪些服务当前是停止或异常状态再决定重启谁。如果只是 vpxd 日志的问题就重启 vpxd如果 vpostgres 也有未释放的大文件那就得重启 vpostgres注意它的重启会带来短暂的数据库不可用vSphere Client 会断开一下。**不推荐的做法是service-control --stop --all然后--start --all。**在空间刚腾出来的情况下全量重启意味着所有服务同时抢着写日志处理时间可能长达十几分钟中途还可能因为某个服务起不来而卡住。除非你面对的是第四阶段那种已经全线崩溃的现场否则逐个处理更稳。最后做验证两个指标df -h /storage/log service-control --status空间有明显的腾出服务列表里关键服务vmware-vpxd、vmware-vpostgres、vmware-vsphere-ui、vmware-stsd是 running 状态就说明止血完成了。接下来再观察半小时隔五分钟看一眼使用率如果还在快速下降说明日志还在疯涨根因没解决得进入下一章的内容。4. 让空间撑得久一点临时收紧日志策略4.1 vpxd 日志级别与轮转参数怎么调清完的空间如果不做任何干预按原来的速度可能一天就又满了。所以在业务时间不方便彻底修根因的情况下我一般会做两件事降低日志级别以及收紧轮转。**降低日志级别。**vpxd 的配置在 /etc/vmware-vpx/vpxd.cfg里面可以配置日志级别。默认级别通常偏详细用来排查问题很友好但在故障循环期间就是灾难。把级别降到 warning能砍掉绝大部分重复的正常流程日志只保留警告和错误。先备份再编辑cp -a /etc/vmware-vpx/vpxd.cfg /etc/vmware-vpx/vpxd.cfg.bak vi /etc/vmware-vpx/vpxd.cfg找到或添加 log 段log levelwarning/level /log保存后重启服务生效service-control --restart vmware-vpxd不同版本支持的级别关键字可能有细微差别通常 info、warning、error 是通用的填错了服务可能起不来所以改完一定要service-control --status确认 vpxd 是 running。部分版本的 vSphere Client 高级设置里也能改 vpxd 相关的日志级别改了同样要重启才生效找不到对应项就直接改配置文件更直接。注意这是个临时措施一定要记账。改完之后如果你自己或者同事后续去查问题会发现日志里什么都看不到。建议在变更记录里写清楚“因日志满临时降级问题解决后恢复”并设个提醒别让它一直留在 warning 上。**收紧轮转。**轮转的目标是让单个文件有上限、归档份数有限制。如果组件自身支持配置文件大小和份数优先用它自己的机制这比外部干预可靠。比如 vpostgres 这类标准组件的日志轮转可以在它自己的配置里调整如果拿不准具体字段就用下面这个兜底方案——定时清归档。find /storage/log/vmware -type f \( -name *.gz -o -name *.old \) -mtime 1 -delete这条命令每天跑一次就足以把归档占用的空间控制在一个可预期的范围内。4.2 其他组件的定向处理除了 vpxd还有几个组件值得单独拎出来说因为它们的日志行为不太一样。**vpostgresql。**数据库的日志通常不大但它有个特点一旦连接数异常或者慢查询堆积日志会瞬间涨。另外它的数据目录在 /storage/db如果那里在涨那就不是日志问题而是数据库膨胀处理思路完全不同别混为一谈。日志部分的处理就是常规截断加归档清理du -sh /storage/log/vmware/vpostgresql find /storage/log/vmware/vpostgresql -type f -name *.gz -mtime 1 -delete**vmdird。**目录服务负责 LDAP 相关的东西。它的日志量跟认证链路健康度强相关。如果它涨得快基本说明认证侧有问题这时候更要保留样本别清完就算tail -n 200 /storage/log/vmware/vmdird/vmdird-syslog.log**vsphere-ui。**HTML5 客户端日志目录在 /storage/log/vmware/vsphere-ui。它的日志在客户端被反复刷新、或者前端报错时会涨得快通常有轮转清理归档就够。**eam。**生命周期管理器负责插件的部署。这个组件平时很安静一旦某个插件部署失败进入重试循环日志会成规模增长。如果发现是 eam 在涨重点不是清日志而是去 vSphere Client 里看是不是有卡住的插件任务。**rhttpproxy。**反向代理日志一般不大属于顺手清一下的类型。我通常是这样组织批量清理的写一个组件清单逐个 du超过阈值的才处理处理完立刻 df 确认避免一次性动作太大出岔子。4.3 一个临时守护脚本如果现场情况是“根因一时半会修不掉但业务不能停”那我会放一个临时守护脚本让它在空间接近阈值时自动做保守清理给自己争取时间。cat /root/log-guard.sh EOF #!/bin/bash # 临时日志守护仅清理归档与截断已知的无价值日志 PART/storage/log THRESHOLD85 USED$(df -P $PART | awk NR2 {gsub(%,,$5); print $5}) [ -z $USED ] exit 0 if [ $USED -ge $THRESHOLD ]; then find /storage/log/vmware -type f \( -name *.gz -o -name *.old \) -mtime 1 -delete 2/dev/null find /storage/log/vmware/vpxd -type f -name *profiler* -delete 2/dev/null # 只有在确实很紧张时才截断当前日志 if [ $USED -ge 95 ]; then : /storage/log/vmware/vpxd/vpxd.log 2/dev/null fi logger -t log-guard log partition used ${USED}%, cleanup executed fi EOF chmod x /root/log-guard.sh然后是加定时任务用crontab -e添加一行每十五分钟跑一次crontab -e # 加入下面这行 */15 * * * * /root/log-guard.sh /dev/null 21脚本里有几个刻意的设计值得解释一下。阈值分两级85% 只清归档95% 才截断当前日志目的是尽量减少对正在排查的问题的干扰。用 logger 打标记这样清理动作会进入 journal事后journalctl -t log-guard就能查到它什么时候动过手不会出现“日志怎么突然少了一段”的无头案。只清理已知路径不做全盘 find避免误伤。注意这个脚本是临时措施不是长期方案。它的正确生命周期是“从故障发现到根因解决”解决了就要删掉否则它会一直悄悄地截断日志哪天你真正需要日志的时候会发现什么都没有。4.4 外送 syslog把日志搬出去才省得彻底清理只能治标真正让本地日志压力下降的方向是外送。VAMI 里有 Syslog 配置项填上远端日志服务器地址和端口vCenter 的日志会同步发一份过去。这里要说清楚一个容易误解的点**外送 syslog 本身不会减少本地日志体积。**它只是多了一份副本。它真正的价值在于——有了外送副本之后你就可以放心地把本地保留周期压到很短甚至激进地缩短归档删除窗口因为需要回溯的时候你去日志服务器上查就行。所以外送的正确用法是配套的两步先在 VAMI 里把 syslog 配好确认日志服务器确实收到了数据在日志服务器上 tail 一下看有没有 vcenter 发来的记录确认没问题之后再把本地的归档保留窗口收紧。配置完之后建议重启一下相关服务或者干脆重启 rsyslog确保配置生效。这一步做完你后面的清理压力会小很多。5. 常见问题与排查速查表5.1 删了文件空间不释放两种典型情况这是清日志过程中最常见的两个“诡异现象”理解了原理就不慌。**第一种deleted-but-open。**前面讲过原理文件被进程持有句柄时删除不释放空间。判断和处理lsof L1 2/dev/null | awk $5 ~ /^[0-9]$/ {print $1, $2, $5, $7, $9} | sort -k3 -n | tail -20输出里关注前两个字段进程名和 PID和大小。找到持有者之后重启对应服务service-control --restart vmware-vpxd重启后df -h立刻就能看到空间回来。如果没有 lsof也可以用ls -l /proc/pid/fd的方式间接确认。**第二种inode 耗尽。**现象是 df -h 说还有空间但任何写操作都报 No space left on device。确认方法就是df -i。如果 IUse% 接近 100%那就得找“大量小文件”的目录。常见的重灾区是各种缓存、临时目录、profiler 碎片目录。定位方法for d in /storage/log/vmware/* /var/log/*; do printf %8d %s\n $(find $d -xdev -type f 2/dev/null | wc -l) $d done | sort -n | tail -15这一条会告诉你哪个目录下文件数量最多。inode 问题通常比空间问题更难处理因为清归档没用得清掉大量小文件本身。5.2 清完日志服务仍然起不来这是第四阶段最常见的窘境。清理只是把空间腾出来了但服务可能已经因为空间不足而把状态写坏了。按下面的顺序排查别瞎重启。先看服务状态和最近的日志service-control --status --all tail -n 100 /storage/log/vmware/vpxd/vpxd.log journalctl -u vmware-vpxd --since 30 min ago | tail -50如果 vpxd 反复启停看日志里的第一条错误通常能定位到是数据库连不上、证书文件损坏还是配置文件被写坏了。如果是配置文件的问题用你之前备份的那份对比一下diff /etc/vmware-vpx/vpxd.cfg /etc/vmware-vpx/vpxd.cfg.bak如果 vpostgres 起不来情况会麻烦一些因为 vpxd 依赖它。这时候看它的日志重点确认数据目录有没有损坏迹象。如果只是暂时连不上单独重启 vpostgresservice-control --restart vmware-vpostgres重启之后稍等一两分钟再启 vpxd给它连接建立的时间。不要两个同时启也不要在 vpostgres 还没起来的时候反复重启 vpxd那只会制造更多错误日志。5.3 高频问题速查表现象大概率原因处理方向/storage/log 100%VAMI 打不开空间耗尽导致服务无法写日志DCUI 开 SSH截断大日志确认服务状态删了文件但 df 空间没变deleted-but-open句柄未释放lsof L1 找持有进程重启对应服务df -h 有空间仍报 No spaceinode 耗尽df -i 确认找小文件最多的目录清理vpxd.log 涨得飞快错误循环常见于证书或认证链路先留样本再清日志然后修根因日志目录里没有归档文件轮转早就失败截断当前日志手动验证轮转可用性清理后半小时又满根因未除日志仍在疯涨临时降级日志级别放守护脚本同步排查根因服务反复启停配置或状态文件被空间不足写坏对比备份配置按依赖顺序逐个重启证书自动续期失败空间不足或时间源异常腾空间后确认 NTP再手动触发续期这张表我在现场是真会打开看的因为人一慌就容易忘记顺序。表格里最容易被忽略的是最后两行——很多时候你以为处理完了其实是把问题推到了几小时之后。实操心得处理完故障之后把“备份了哪些文件、改了哪些参数、临时加了什么脚本”列一个清单一次性回滚干净。日志类故障特别容易留下“临时措施变成永久配置”的后遗症我见过太多环境里 vpxd 日志级别还停在 warning出问题时谁都查不到东西。6. 从临时手段到长效方案6.1 容量规划与分区扩容的正确姿势临时手段解决的是“今天不能停机”但如果你管理的环境里已经出现过一次日志满那大概率还会有第二次这时候就得考虑容量层面的调整。**第一件事是搞清楚当前分区的实际容量和增长趋势。**拿两天的 df 数据做个简单推算就能估出“按当前速度多久会满”。如果估出来是不到一周那扩容就该排上日程了。**扩容 VCSA 的分区不是简单地在 vSphere Client 里加大磁盘就完事。**直接改虚拟机磁盘大小guest 里的分区和文件系统不会自动跟着变你需要用分区工具扩展分区、再扩展文件系统而且这个操作通常需要把设备关机、用 ISO 引导或者挂到别的环境里做。整个过程对业务是有中断的所以它属于计划内维护绝不能当成救火手段用。正因为扩容麻烦我通常建议的顺序是先做日志外送再收紧本地保留周期如果这两招还不够说明日志量本身就异常那就该去查根因而不是扩容。真正需要扩容的场景一般是设备规模变大管的主机数、虚拟机数涨了导致日志基线上升这种情况扩容是合理的。按部署规模参考小规模环境的日志分区通常在 10GB 上下中大规模在 15GB 到 20GB 这个区间。如果你的环境规模已经接近下一个档位规划的时候直接按上档位走别卡着边界配。6.2 该盯的监控项与告警阈值日志满这件事最好的处理时机永远是它还没满的时候。所以我建议把下面几个指标做成固定监控接入到现有的监控系统里。监控项建议阈值说明/storage/log 使用率警告 80%严重 90%最核心的指标优先做/storage/log inode 使用率警告 85%独立于空间的另一条命/storage/core 目录体积超过 5GB 告警说明有服务在反复崩溃vpxd 服务状态非 running 即告警依赖关系里最关键的一环日志目录增长速率单日增长超 1GB 告警比绝对体积更早暴露问题证书剩余有效期剩余 60 天告警从源头掐断连锁反应这些指标在 VAMI 里能拿到一部分剩下的可以从命令行采集写个简单的脚本定时上报就行。关键是阈值要有人看告警发出来没人处理等于没做。我自己的经验是阈值定得低一点比高一点好。80% 警告听起来很保守但考虑到日志增长经常是突发的、非线性的从 80% 到 100% 可能只需要一个下午。留出处理窗口比追求“不要误报”重要得多。6.3 我个人踩过的三个坑最后说三个我自己真金白银踩过的坑都是文档里不会写、但在现场特别容易犯的。**第一个坑先删后想。**刚入行那会儿遇到日志满第一反应就是rm大文件删完发现 df 没变然后慌了接着去重启服务结果把正在进行的排查线索全清掉了。后来我的习惯固定成先du定位先tail留样本先cp备份配置最后才动手清。多花的三分钟能省掉后面三个小时。**第二个坑把临时配置忘在环境里。**有一次为了压日志量把级别降到 warning问题解决后忘了改回来。两个月后另一批同事排查一个性能问题翻遍日志找不到线索最后才发现级别还停在 warning。从那以后我改任何参数都会在变更记录里写一行“必须回滚”并且在日历上设一个提醒。**第三个坑只清不修。**日志满是一个症状不是一个故障。我见过同一台 vCenter 在三个月里被清了四次日志每次都是清完就走直到有人终于去看了下 vpxd.log 里的错误发现是证书早就过期了修完之后日志量直接掉了九成。所以清日志这个动作做完之后一定要留一点时间给“为什么”哪怕当时只能记下几句关键字也比纯粹的删除有价值。日志分区满这件事处理起来的技术门槛其实不高真正难的是在压力下保持顺序感先定位、再留证据、然后截断、接着验证、最后收口。把这套流程走顺了大部分现场都能在半小时内把 vCenter 从半死状态拉回来剩下的时间就可以从容地去修根因了。
vCenter /storage/log 写满：十分钟止血与长效治理
接手过不少 vCenter 半死不活的现场真正因为证书链断了、数据库崩了导致整台设备趴下的次数其实远没有“磁盘写满”来得多。而所有磁盘写满里/storage/log 被日志撑爆又是绝对的头号选手。日志满这件事最阴的地方在于它不会一上来就把 vCenter 打死——先是任务提交变慢接着 vSphere Client 登录转圈再然后是 VAMI 打不开、服务起不来、证书自动续期失败等你发现的时候已经是一堆故障叠在一起了。这篇东西不讲大道理就讲我在现场怎么在十分钟内把空间腾出来、怎么让腾出来的空间撑得久一点、以及哪些操作看着解气实际上会把事情搞得更糟。适合手里正捏着一台告警的 vCenter、又不想在业务时间重启整台设备的运维同行也适合刚接手虚拟化平台、还没遇到过这种场面的朋友。1. vCenter 日志满的真实表现与根因拆解1.1 故障现场长什么样从“还能登”到“登不上”的四个阶段我见过的 vCenter 因为日志满引发的故障基本都会沿着一条比较固定的路径往下滑识别出自己在第几阶段直接决定了你能不能只清日志就把事情压下去。第一阶段是“感知迟钝期”。这个阶段你几乎察觉不到异常只有 VAMI 首页的存储用量卡片开始泛黄/storage/log 的使用率爬到 80% 以上。此时任务还能提交虚拟机还能正常开机唯一的变化是 vSphere Client 里某些页面加载会顿一下——因为 vpxd 在往已经很大的日志文件里追加内容写入变慢间接拖累了响应。这个阶段动手成本最低可惜绝大多数人都是被后面的阶段叫醒的。第二阶段是“功能局部失灵期”。使用率过了 95%一些依赖写日志的服务开始报错。表现是任务提交成功但卡在“进行中”不动告警里开始出现“无法完成操作”之类的模糊提示证书自动续期任务静默失败。这时候你去 VAMI 看服务列表里会有一两个显示为黄色或红色但点“启动”又起不来。第三阶段是“服务连环倒”。100% 满了之后服务写不了日志就直接退出而 vCenter 的很多服务是互相依赖的vpxd 依赖 vpostgresvsphere-ui 依赖 vpxdvmon 又在看着所有服务的状态试图拉起来。这时候你打开 VAMI 会得到 503SSH 进去执行 service-control 也会报错因为连 service-control 自己都要往 /var/log 里写东西——而 /var/log 在 VCSA 里就是 /storage/log 的软链。第四阶段是“恢复困难期”。这个阶段最难受的其实不是空间而是空间腾出来之后服务依然起不来配置写到一半被中断、数据库的 WAL 没落盘、证书续期写坏了文件。所以我自己的原则是只要看到使用率超过 90%不管业务有没有反馈当天必须处理。1.2 /storage 分区地图哪些目录才是日志的真正大户很多人第一次 SSH 进 VCSA看到 /storage 下面一堆目录会有点懵。先把这张地图记住后面定位问题会快很多。路径主要内容能不能清/storage/log所有组件日志/var/log 的软链目标能清优先清这里/storage/core服务崩溃产生的 core dump确认无工单后可清/storage/dbvpostgres 数据目录绝对不能动/storage/seat遥测与统计相关数据不要手删走配置关闭/storage/archive归档类数据谨慎先确认用途/storage/imagebuilder镜像配置文件不要动/storage/updatemgr补丁与更新缓存可清缓存不要删目录/storage/autodeploy自动部署配置不要动/storage/log 的默认容量跟部署规模挂钩小规模环境通常在 10GB 上下中大规模一般落在 15GB 到 20GB 这个区间具体数值以 df 输出为准别凭记忆判断。真正容易出事的是很多人以为日志分区 20GB 很大但 vpxd 一个组件在异常状态下一天写掉几个 GB 是常事。在这个分区里按体量排下来通常是这么个顺序vpxd 目录第一vpxd.log 加上一堆归档异常时能到几十 GBvpxd-profiler 之类的剖析输出第二单文件动辄几个 GB而且是纯性能剖析数据没有任何排查价值vpostgresql 和 vmdird 第三平时不大一旦数据库或认证链路有问题就会暴涨vsphere-ui、eam、rhttpproxy 这些属于“平时安静、出事就疯”的类型。还有两个不常被想起来的地方一个是 /storage/core 里的 core dump服务崩溃时会产生单个文件可能就有好几个 GB而且崩溃往往是循环发生的一次故障下来能攒出十几个另一个是 systemd 的 journal位于 /var/log/journal默认会自己控制大小但在异常刷屏的场景下同样能吃掉几个 GB。1.3 五类高频根因为什么日志会在几天内涨满清日志只是止血搞清楚“为什么涨”才能决定清完之后要不要立刻做别的动作。我按遇到频率排了个序。**第一类vpxd 陷入错误循环。**这是最常见的。vpxd 在向某个外部依赖数据库、SSO、AD、其他 vCenter 节点发起请求失败后会以很高的频率重试并记录错误每条错误都是一段带堆栈的文本。我见过最夸张的一次vpxd.log 每小时涨 1.5GB原因只是 SSO 那边某个服务的连接被防火墙策略挡掉了。判断方法很简单tail 一下 vpxd.log如果满屏都是同一条错误基本就是这个原因。**第二类日志轮转本身失效。**这是个很隐蔽的正反馈循环轮转需要创建新文件、需要重命名旧文件而这些都是写操作磁盘接近满的时候轮转会失败于是组件继续往同一个文件里追加文件越来越大轮转更不可能成功。所以你会看到一个几十 GB 的 vpxd.log旁边一个归档文件都没有——这本身就是“轮转早就挂了”的信号。**第三类服务崩溃刷 core dump。**某个组件因为内存或依赖问题反复崩溃每次崩溃都往 /storage/core 里丢一个体积不小的核心转储文件。这类故障的特点是空间掉得特别快而且 du 出来你会发现在 /storage/log 里找不到大头问题在 /storage/core。**第四类第三方插件或扩展在报错。**比如某些备份软件、监控代理、存储插件装到 vCenter 上它们自己的日志也在往 /storage/log 里写。这类日志通常位于 /storage/log/vmware/ 下以插件命名的目录或者干脆在 /var/log 根下。清理的时候顺手看一眼别只盯着 VMware 自己的目录。**第五类认证与证书相关的重试风暴。**这一类我要单独展开说因为这个坑我踩过。1.4 借“证书过期”说个连锁反应vCenter 的证书过期是个很典型的多米诺证书一过期所有依赖证书的组件间通信开始失败每个失败都会被各组件记一条错误组件发现失败后会重试重试有间隔但往往很短于是日志以异常的速度增长把 /storage/log 撑满空间满了之后证书自动续期任务因为写不了文件而失败证书续不回来错误继续刷日志继续涨。我在一个客户现场就遇到过这套组合拳早上八点开始有人反馈登录慢十点 vSphere Client 打不开中午我拿到现场vpxd.log 已经 34GB/storage/log 显示 100%VAMI 的 503。attr 顺序很清楚——先把空间腾出来再处理证书顺序反了会白忙一场。这里有个经验值得记下来**当你看到日志里大量出现认证、连接、证书之类的关键字并且频率高得不正常先别急着删日志先记下错误原文和时间戳。**因为清完日志再重启服务这些证据就没了而你马上就要用它们去定位根因。我一般会在清理前做一件事mkdir -p /root/incident-$(date %Y%m%d) grep -i -m 200 -E cert|ssl|auth|refused|timeout /storage/log/vmware/vpxd/vpxd.log \ /root/incident-$(date %Y%m%d)/vpxd-sample.log tail -n 500 /storage/log/vmware/vpxd/vpxd.log \ /root/incident-$(date %Y%m%d)/vpxd-tail.log这两条命令只花几秒钟占用几十 MB但保留了最关键的信息。等空间腾出来之后你就可以拿着这份样本去对着时间线看比在几十 GB 的日志里翻要省事太多。注意如果你正在跟厂商开支持工单/storage/core 里的核心转储文件先别删哪怕它很大。删掉之后再想复现成本会高得多。2. 救火前的准备入口、备份与操作边界2.1 三条登录入口与各自的适用场景日志满的时候登录方式本身就是个问题不同阶段能用的入口不一样提前知道有哪几条路现场会从容很多。**第一条是 SSH。**正常情况下用 root 账号 SSH 到 vCenter 的 IP进去是 appliancesh受限的命令行外壳需要再敲shell才能进 Bash。空间没满的时候这条路最顺。但如果已经到第三阶段SSH 可能连不上因为 sshd 也需要写日志。**第二条是 VAMI。**浏览器访问https://vcenter-ip:5480用 root 登录这里是图形化界面能做服务启停、能看存储用量、能配置 syslog 和备份。它的优势是不依赖 SSH 通道劣势是空间满的情况下它自己也起不来。**第三条是 DCUI也是最后的底牌。**在 vSphere Client 或 ESXi 主机客户端里找到 vCenter 这台虚拟机的控制台直接打开看到的是一个黑底菜单。里面有个 Troubleshooting Options故障排除选项可以临时启用 SSH 和启用 Bash Shell。这条路的好处是完全绕开 guest OS 里的服务图形控制台是 ESXi 层提供的只要虚拟机能开机就能用。我的实际操作顺序是先试 SSH连不上走 DCUI 打开 SSH 和 Bash再用 SSH 进去干活。DCUI 里还有个 Restart Management Agents 的选项一般不用碰因为 VCSA 不是 ESXi那个选项在里面意义有限别乱按。2.2 动手前必须做的三件小事日志清理由看起来是“删东西”但职业习惯要求你在动手前做几个确认动作这几个动作总共花不到两分钟。**第一件确认这台设备最近有没有被人改过。**比如是不是刚做过升级、刚换过证书、刚装过插件。这些信息决定了你后面是只清日志还是要顺手处理别的。如果团队里有变更记录翻一眼没有的话看几个文件的修改时间也能猜个八九不离十ls -l --time-stylelong-iso /etc/vmware-vpx/vpxd.cfg ls -lt --time-stylelong-iso /storage/log/vmware/ | head**第二件确认当前的空间分布和 inode 使用情况。**很多人只看 df -h不看 inode。inode 耗尽的情况下df -h 显示还有空间但任何写操作都会报 “No space left on device”这是另外一个完全不同的排查方向先排除掉能省很多时间。df -h df -i**第三件把要改的配置文件备份掉。**如果你打算调整日志级别或者其他参数先cp一份带日期的备份。这是纪律不是可选项。cp -a /etc/vmware-vpx/vpxd.cfg /etc/vmware-vpx/vpxd.cfg.bak-$(date %Y%m%d%H%M)提示日志满的时候不要创建虚拟机快照。虽然快照本身落在存储上看似不占 guest 空间但快照会冻结瞬时 I/O、产生 Delta 文件在你还没搞清楚状况之前增加一个变量得不偿失。清理日志这种操作不动配置风险本来就是可控的。2.3 什么能删、什么打死不能删这一节是我认为最该先看的部分。现场慌乱的时候最容易发生的就是rm -rf /storage/log/*这类操作看着解气后果是某些服务因为找不到预期的日志目录而启动失败而且不会自动重建。**可以放心处理的**已经轮转出来的归档文件名字里带.gz、.old、.1这类后缀的vpxd-profiler 之类的性能剖析输出/storage/core 里超过一定天数的核心转储前提是没有正在跟进的工单/storage/updatemgr 里的旧补丁缓存。**只能截断不能删除的**所有正在被进程写入的当前日志文件比如 vpxd.log、vpostgresql 的当前日志。对这类文件删除不会释放空间下面会详细讲必须用截断的方式清零。打死不能动的/storage/db 下的任何内容尤其是 vpostgres 的数据目录和 WAL 文件动一下数据库可能就废了/etc 下的任何配置文件/storage/seat、/storage/imagebuilder、/storage/autodeploy 这些目录本身。**判断标准很简单**如果这个路径是某个服务启动参数里指定的目录那它就应该保留如果只是历史产物那就可以清。拿不准的时候只清归档文件和 profiler这两个基本不会出问题。3. 临时止血命令行腾空间的完整实操3.1 第一步用 vdf、df、du 三层定位到具体目录定位这件事要有顺序从粗到细不要一上来就 find 整个文件系统那样又慢又费 IO。**第一层看分区级使用率。**VCSA 里有个挺好用的命令叫vdf -h它输出的视角和 VAMI、DCUI 看到的更接近能直接告诉你哪个分区该管。当然df -h也可以用两个一起看更保险。vdf -h df -h df -i**第二层看一级目录的体量。**这一步能让你三秒钟内知道问题在 /storage/log 还是在 /storage/core。du -sh /storage/* 2/dev/null | sort -h**第三层钻到具体组件。**如果确认是 log 分区继续往下拆du -sh /storage/log/vmware/* 2/dev/null | sort -h du -sh /var/log/* 2/dev/null | sort -h | tail -20到这一层基本就水落石出了。如果还是找不到大头说明可能是大量中小文件堆积或者空间被“已删除但被占用”的文件吃掉了这时候改用查找大文件的思路find /storage/log -xdev -type f -size 500M -printf %s\t%p\n 2/dev/null \ | sort -n | awk {printf %.1f MB\t%s\n, $1/1048576, $2}这条命令会列出 /storage/log 下所有超过 500MB 的文件从小到大排序最后几行就是你要处理的。用-xdev是为了不跨分区避免把整个存储都扫一遍。3.2 第二步截断而不是删除以及为什么这是全文最重要的一个技术点。在 Linux 里删除一个文件只是把目录项摘掉如果还有进程持有这个文件的句柄文件的数据块并不会被释放df看到的可用空间也不会变。日志文件恰恰是被服务长期打开着的所以你rm掉一个 20GB 的 vpxd.logdf可能纹丝不动——空间要等到 vpxd 重启、句柄关闭之后才会真正释放。正确做法是截断也就是把文件内容清零但保留文件本身和它的 inode# 方式一最简单重定向一个空内容进去 : /storage/log/vmware/vpxd/vpxd.log # 方式二语义更明确 truncate -s 0 /storage/log/vmware/vpxd/vpxd.log截断是立即生效的持有句柄的进程不会报错它会继续往后写偏移量从新文件末尾接着算不影响服务运行。这是日志满场景下最优雅的止血方式。**批量处理的时候要注意顺序。**先清归档那些不需要保留句柄的再截断当前日志。归档文件用 rm 删是安全的find /storage/log/vmware -type f \( -name *.gz -o -name *.old -o -name *.1 \) -mtime 1 -print先把-print跑一遍看清单确认没有误伤再换成-delete执行。这个习惯我建议一直保留尤其是命令里带通配符的时候。注意不要一次性截断所有组件的当前日志。有些服务在日志文件被外部修改时会重新打开文件极端情况下可能因为短暂的竞争条件产生报错。稳妥的做法是逐个组件处理处理完一个df -h看一眼。3.3 第三步清理 core dump、profiler 与历史归档这三类东西是清空间的“高性价比目标”因为它们体积大、没有保留价值、删除风险低。core dump在 /storage/core 下通常是服务崩溃时生成的二进制文件。清理前先看体积和时间分布du -sh /storage/core find /storage/core -type f -mtime 7 -printf %TY-%Tm-%Td %10s %p\n 2/dev/null | sort | tail -20确认清单合理之后再按时间清理比如保留最近七天find /storage/core -type f -mtime 7 -delete如果 /storage/core 里有正在被写入的 core 文件也就是服务还在持续崩溃光删是没用的得先解决崩溃本身。判断方法看文件名的时间戳是不是“刚刚”隔一分钟再看一次还在不在。profiler 输出是我个人最推荐优先清理的东西。它位于 vpxd 的日志目录里文件名一般以 profiler 开头动辄几个 GB而且除了厂商深度性能分析场景日常运维完全用不到find /storage/log/vmware/vpxd -maxdepth 1 -type f -name *profiler* -printf %s\t%p\n 2/dev/null | sort -n确认之后直接删。不同版本里这个文件的命名可能略有差异以实际 find 结果为准别看名字猜。历史归档就是前面提到的 .gz、.old 这批清的时候可以按天粒度保留比如只留最近两天。3.4 第四步给 systemd journal 和系统日志瘦身这一步经常被忽略但在刷屏场景下收益不小。VCSA 基于 systemdsystemd-journald 会把内核和服务日志写到 /var/log/journal 里默认能吃几个 GB。journalctl --disk-usage journalctl --vacuum-size200M journalctl --vacuum-time7d--vacuum-size是压到指定大小以下--vacuum-time是按时间清理两个可以配合用。执行完之后再journalctl --disk-usage确认一下。如果你希望这个限制长期生效改配置文件vi /etc/systemd/journald.conf把#SystemMaxUse那一行的注释去掉改成SystemMaxUse200M然后重启 journaldsystemctl restart systemd-journald这个改动是“临时手段里带一点长效”的性质我一般会顺手做掉因为 journal 在故障期间刷屏特别厉害200MB 的上限既够用又不会失控。系统侧的 /var/log/messages、/var/log/secure 这类文件走的是 logrotate配置在 /etc/logrotate.d/ 下面正常情况下不用改但如果发现有单个文件特别大可以临时手动轮转一次logrotate -f /etc/logrotate.conf3.5 第五步服务重启与空间回收验证清完之后有一件事必须确认**被删掉但还被句柄持有的文件有没有需要重启服务才能释放。**检查方法lsof L1 2/dev/null | head -30这条命令列出所有“链接数为 0 但仍有进程打开”的文件也就是已删除未释放的。如果输出里出现大文件并且关联的是 vpxd、vpostgres 这类关键服务那部分空间就得靠重启服务才能拿回来。重启单个服务是安全的用 service-controlservice-control --status --all service-control --restart vmware-vpxd--status先看一眼全局确认哪些服务当前是停止或异常状态再决定重启谁。如果只是 vpxd 日志的问题就重启 vpxd如果 vpostgres 也有未释放的大文件那就得重启 vpostgres注意它的重启会带来短暂的数据库不可用vSphere Client 会断开一下。**不推荐的做法是service-control --stop --all然后--start --all。**在空间刚腾出来的情况下全量重启意味着所有服务同时抢着写日志处理时间可能长达十几分钟中途还可能因为某个服务起不来而卡住。除非你面对的是第四阶段那种已经全线崩溃的现场否则逐个处理更稳。最后做验证两个指标df -h /storage/log service-control --status空间有明显的腾出服务列表里关键服务vmware-vpxd、vmware-vpostgres、vmware-vsphere-ui、vmware-stsd是 running 状态就说明止血完成了。接下来再观察半小时隔五分钟看一眼使用率如果还在快速下降说明日志还在疯涨根因没解决得进入下一章的内容。4. 让空间撑得久一点临时收紧日志策略4.1 vpxd 日志级别与轮转参数怎么调清完的空间如果不做任何干预按原来的速度可能一天就又满了。所以在业务时间不方便彻底修根因的情况下我一般会做两件事降低日志级别以及收紧轮转。**降低日志级别。**vpxd 的配置在 /etc/vmware-vpx/vpxd.cfg里面可以配置日志级别。默认级别通常偏详细用来排查问题很友好但在故障循环期间就是灾难。把级别降到 warning能砍掉绝大部分重复的正常流程日志只保留警告和错误。先备份再编辑cp -a /etc/vmware-vpx/vpxd.cfg /etc/vmware-vpx/vpxd.cfg.bak vi /etc/vmware-vpx/vpxd.cfg找到或添加 log 段log levelwarning/level /log保存后重启服务生效service-control --restart vmware-vpxd不同版本支持的级别关键字可能有细微差别通常 info、warning、error 是通用的填错了服务可能起不来所以改完一定要service-control --status确认 vpxd 是 running。部分版本的 vSphere Client 高级设置里也能改 vpxd 相关的日志级别改了同样要重启才生效找不到对应项就直接改配置文件更直接。注意这是个临时措施一定要记账。改完之后如果你自己或者同事后续去查问题会发现日志里什么都看不到。建议在变更记录里写清楚“因日志满临时降级问题解决后恢复”并设个提醒别让它一直留在 warning 上。**收紧轮转。**轮转的目标是让单个文件有上限、归档份数有限制。如果组件自身支持配置文件大小和份数优先用它自己的机制这比外部干预可靠。比如 vpostgres 这类标准组件的日志轮转可以在它自己的配置里调整如果拿不准具体字段就用下面这个兜底方案——定时清归档。find /storage/log/vmware -type f \( -name *.gz -o -name *.old \) -mtime 1 -delete这条命令每天跑一次就足以把归档占用的空间控制在一个可预期的范围内。4.2 其他组件的定向处理除了 vpxd还有几个组件值得单独拎出来说因为它们的日志行为不太一样。**vpostgresql。**数据库的日志通常不大但它有个特点一旦连接数异常或者慢查询堆积日志会瞬间涨。另外它的数据目录在 /storage/db如果那里在涨那就不是日志问题而是数据库膨胀处理思路完全不同别混为一谈。日志部分的处理就是常规截断加归档清理du -sh /storage/log/vmware/vpostgresql find /storage/log/vmware/vpostgresql -type f -name *.gz -mtime 1 -delete**vmdird。**目录服务负责 LDAP 相关的东西。它的日志量跟认证链路健康度强相关。如果它涨得快基本说明认证侧有问题这时候更要保留样本别清完就算tail -n 200 /storage/log/vmware/vmdird/vmdird-syslog.log**vsphere-ui。**HTML5 客户端日志目录在 /storage/log/vmware/vsphere-ui。它的日志在客户端被反复刷新、或者前端报错时会涨得快通常有轮转清理归档就够。**eam。**生命周期管理器负责插件的部署。这个组件平时很安静一旦某个插件部署失败进入重试循环日志会成规模增长。如果发现是 eam 在涨重点不是清日志而是去 vSphere Client 里看是不是有卡住的插件任务。**rhttpproxy。**反向代理日志一般不大属于顺手清一下的类型。我通常是这样组织批量清理的写一个组件清单逐个 du超过阈值的才处理处理完立刻 df 确认避免一次性动作太大出岔子。4.3 一个临时守护脚本如果现场情况是“根因一时半会修不掉但业务不能停”那我会放一个临时守护脚本让它在空间接近阈值时自动做保守清理给自己争取时间。cat /root/log-guard.sh EOF #!/bin/bash # 临时日志守护仅清理归档与截断已知的无价值日志 PART/storage/log THRESHOLD85 USED$(df -P $PART | awk NR2 {gsub(%,,$5); print $5}) [ -z $USED ] exit 0 if [ $USED -ge $THRESHOLD ]; then find /storage/log/vmware -type f \( -name *.gz -o -name *.old \) -mtime 1 -delete 2/dev/null find /storage/log/vmware/vpxd -type f -name *profiler* -delete 2/dev/null # 只有在确实很紧张时才截断当前日志 if [ $USED -ge 95 ]; then : /storage/log/vmware/vpxd/vpxd.log 2/dev/null fi logger -t log-guard log partition used ${USED}%, cleanup executed fi EOF chmod x /root/log-guard.sh然后是加定时任务用crontab -e添加一行每十五分钟跑一次crontab -e # 加入下面这行 */15 * * * * /root/log-guard.sh /dev/null 21脚本里有几个刻意的设计值得解释一下。阈值分两级85% 只清归档95% 才截断当前日志目的是尽量减少对正在排查的问题的干扰。用 logger 打标记这样清理动作会进入 journal事后journalctl -t log-guard就能查到它什么时候动过手不会出现“日志怎么突然少了一段”的无头案。只清理已知路径不做全盘 find避免误伤。注意这个脚本是临时措施不是长期方案。它的正确生命周期是“从故障发现到根因解决”解决了就要删掉否则它会一直悄悄地截断日志哪天你真正需要日志的时候会发现什么都没有。4.4 外送 syslog把日志搬出去才省得彻底清理只能治标真正让本地日志压力下降的方向是外送。VAMI 里有 Syslog 配置项填上远端日志服务器地址和端口vCenter 的日志会同步发一份过去。这里要说清楚一个容易误解的点**外送 syslog 本身不会减少本地日志体积。**它只是多了一份副本。它真正的价值在于——有了外送副本之后你就可以放心地把本地保留周期压到很短甚至激进地缩短归档删除窗口因为需要回溯的时候你去日志服务器上查就行。所以外送的正确用法是配套的两步先在 VAMI 里把 syslog 配好确认日志服务器确实收到了数据在日志服务器上 tail 一下看有没有 vcenter 发来的记录确认没问题之后再把本地的归档保留窗口收紧。配置完之后建议重启一下相关服务或者干脆重启 rsyslog确保配置生效。这一步做完你后面的清理压力会小很多。5. 常见问题与排查速查表5.1 删了文件空间不释放两种典型情况这是清日志过程中最常见的两个“诡异现象”理解了原理就不慌。**第一种deleted-but-open。**前面讲过原理文件被进程持有句柄时删除不释放空间。判断和处理lsof L1 2/dev/null | awk $5 ~ /^[0-9]$/ {print $1, $2, $5, $7, $9} | sort -k3 -n | tail -20输出里关注前两个字段进程名和 PID和大小。找到持有者之后重启对应服务service-control --restart vmware-vpxd重启后df -h立刻就能看到空间回来。如果没有 lsof也可以用ls -l /proc/pid/fd的方式间接确认。**第二种inode 耗尽。**现象是 df -h 说还有空间但任何写操作都报 No space left on device。确认方法就是df -i。如果 IUse% 接近 100%那就得找“大量小文件”的目录。常见的重灾区是各种缓存、临时目录、profiler 碎片目录。定位方法for d in /storage/log/vmware/* /var/log/*; do printf %8d %s\n $(find $d -xdev -type f 2/dev/null | wc -l) $d done | sort -n | tail -15这一条会告诉你哪个目录下文件数量最多。inode 问题通常比空间问题更难处理因为清归档没用得清掉大量小文件本身。5.2 清完日志服务仍然起不来这是第四阶段最常见的窘境。清理只是把空间腾出来了但服务可能已经因为空间不足而把状态写坏了。按下面的顺序排查别瞎重启。先看服务状态和最近的日志service-control --status --all tail -n 100 /storage/log/vmware/vpxd/vpxd.log journalctl -u vmware-vpxd --since 30 min ago | tail -50如果 vpxd 反复启停看日志里的第一条错误通常能定位到是数据库连不上、证书文件损坏还是配置文件被写坏了。如果是配置文件的问题用你之前备份的那份对比一下diff /etc/vmware-vpx/vpxd.cfg /etc/vmware-vpx/vpxd.cfg.bak如果 vpostgres 起不来情况会麻烦一些因为 vpxd 依赖它。这时候看它的日志重点确认数据目录有没有损坏迹象。如果只是暂时连不上单独重启 vpostgresservice-control --restart vmware-vpostgres重启之后稍等一两分钟再启 vpxd给它连接建立的时间。不要两个同时启也不要在 vpostgres 还没起来的时候反复重启 vpxd那只会制造更多错误日志。5.3 高频问题速查表现象大概率原因处理方向/storage/log 100%VAMI 打不开空间耗尽导致服务无法写日志DCUI 开 SSH截断大日志确认服务状态删了文件但 df 空间没变deleted-but-open句柄未释放lsof L1 找持有进程重启对应服务df -h 有空间仍报 No spaceinode 耗尽df -i 确认找小文件最多的目录清理vpxd.log 涨得飞快错误循环常见于证书或认证链路先留样本再清日志然后修根因日志目录里没有归档文件轮转早就失败截断当前日志手动验证轮转可用性清理后半小时又满根因未除日志仍在疯涨临时降级日志级别放守护脚本同步排查根因服务反复启停配置或状态文件被空间不足写坏对比备份配置按依赖顺序逐个重启证书自动续期失败空间不足或时间源异常腾空间后确认 NTP再手动触发续期这张表我在现场是真会打开看的因为人一慌就容易忘记顺序。表格里最容易被忽略的是最后两行——很多时候你以为处理完了其实是把问题推到了几小时之后。实操心得处理完故障之后把“备份了哪些文件、改了哪些参数、临时加了什么脚本”列一个清单一次性回滚干净。日志类故障特别容易留下“临时措施变成永久配置”的后遗症我见过太多环境里 vpxd 日志级别还停在 warning出问题时谁都查不到东西。6. 从临时手段到长效方案6.1 容量规划与分区扩容的正确姿势临时手段解决的是“今天不能停机”但如果你管理的环境里已经出现过一次日志满那大概率还会有第二次这时候就得考虑容量层面的调整。**第一件事是搞清楚当前分区的实际容量和增长趋势。**拿两天的 df 数据做个简单推算就能估出“按当前速度多久会满”。如果估出来是不到一周那扩容就该排上日程了。**扩容 VCSA 的分区不是简单地在 vSphere Client 里加大磁盘就完事。**直接改虚拟机磁盘大小guest 里的分区和文件系统不会自动跟着变你需要用分区工具扩展分区、再扩展文件系统而且这个操作通常需要把设备关机、用 ISO 引导或者挂到别的环境里做。整个过程对业务是有中断的所以它属于计划内维护绝不能当成救火手段用。正因为扩容麻烦我通常建议的顺序是先做日志外送再收紧本地保留周期如果这两招还不够说明日志量本身就异常那就该去查根因而不是扩容。真正需要扩容的场景一般是设备规模变大管的主机数、虚拟机数涨了导致日志基线上升这种情况扩容是合理的。按部署规模参考小规模环境的日志分区通常在 10GB 上下中大规模在 15GB 到 20GB 这个区间。如果你的环境规模已经接近下一个档位规划的时候直接按上档位走别卡着边界配。6.2 该盯的监控项与告警阈值日志满这件事最好的处理时机永远是它还没满的时候。所以我建议把下面几个指标做成固定监控接入到现有的监控系统里。监控项建议阈值说明/storage/log 使用率警告 80%严重 90%最核心的指标优先做/storage/log inode 使用率警告 85%独立于空间的另一条命/storage/core 目录体积超过 5GB 告警说明有服务在反复崩溃vpxd 服务状态非 running 即告警依赖关系里最关键的一环日志目录增长速率单日增长超 1GB 告警比绝对体积更早暴露问题证书剩余有效期剩余 60 天告警从源头掐断连锁反应这些指标在 VAMI 里能拿到一部分剩下的可以从命令行采集写个简单的脚本定时上报就行。关键是阈值要有人看告警发出来没人处理等于没做。我自己的经验是阈值定得低一点比高一点好。80% 警告听起来很保守但考虑到日志增长经常是突发的、非线性的从 80% 到 100% 可能只需要一个下午。留出处理窗口比追求“不要误报”重要得多。6.3 我个人踩过的三个坑最后说三个我自己真金白银踩过的坑都是文档里不会写、但在现场特别容易犯的。**第一个坑先删后想。**刚入行那会儿遇到日志满第一反应就是rm大文件删完发现 df 没变然后慌了接着去重启服务结果把正在进行的排查线索全清掉了。后来我的习惯固定成先du定位先tail留样本先cp备份配置最后才动手清。多花的三分钟能省掉后面三个小时。**第二个坑把临时配置忘在环境里。**有一次为了压日志量把级别降到 warning问题解决后忘了改回来。两个月后另一批同事排查一个性能问题翻遍日志找不到线索最后才发现级别还停在 warning。从那以后我改任何参数都会在变更记录里写一行“必须回滚”并且在日历上设一个提醒。**第三个坑只清不修。**日志满是一个症状不是一个故障。我见过同一台 vCenter 在三个月里被清了四次日志每次都是清完就走直到有人终于去看了下 vpxd.log 里的错误发现是证书早就过期了修完之后日志量直接掉了九成。所以清日志这个动作做完之后一定要留一点时间给“为什么”哪怕当时只能记下几句关键字也比纯粹的删除有价值。日志分区满这件事处理起来的技术门槛其实不高真正难的是在压力下保持顺序感先定位、再留证据、然后截断、接着验证、最后收口。把这套流程走顺了大部分现场都能在半小时内把 vCenter 从半死状态拉回来剩下的时间就可以从容地去修根因了。
