★ FEATURED ARTICLE 凌晨两点接到电话说 vCenter 登不上了vSphere Client 里所有主机和虚拟机全是灰色的SSH 敲进去一看df -h显示某个分区 100%。这种场面做虚拟化运维的基本都遇到过十次里有七八次就是vCenter 日志满惹的祸。vCenter Server ApplianceVCSA给日志划的分区是固定的一旦某个组件开始疯狂刷日志——最常见的几个老熟人就是 vpxd、vmdird、vsphere-ui——分区撑满之后写不进去日志服务自己就崩了接着整条管理链路跟着挂。这篇文章不谈理论就把我这些年处理 VCSA 7.0 和 8.0 日志撑爆时用的临时止血流程完整讲一遍怎么在三分钟内定位到是哪个目录吃掉了空间、哪些日志能直接清、被进程占用的文件怎么清才真的释放空间、清完之后服务起不来怎么救以及留在环境里那几个半永久的调优动作。内容偏实操刚接手 VCSA 的新手能照着抄老手也可以对着速查表核一遍自己的流程。1. vCenter日志满是什么症状先看清病再动手1.1 从告警到服务全趴的典型演进路径vCenter 日志满这件事几乎不会一上来就报磁盘空间不足它是一步一步烂下去的中间有好几个可以拦截的窗口期可惜大部分人第一次遇到时都错过了。第一阶段的信号通常很温和vSphere Client 登录变慢操作一台虚拟机要转圈十几秒任务列表刷新卡顿性能图表点进去半天不出数据。这时候日志分区大概已经到 85% 到 90% 了各个服务还在正常工作只是写日志的 I/O 变慢间接拖累了整体响应。第二阶段就开始明显了某个具体功能报错比如无法启动虚拟机、无法创建快照、清单对象加载失败登录时提示认证服务异常。这一步通常是被撑满的那个分区已经到 95% 以上部分组件的日志写不进去直接抛异常。第三阶段是最惨的vpxdvCenter 的核心服务反复重启vsphere-ui起不来STS 认证失败所有主机在清单里变成灰色你连登录页面都打不开只能靠 SSH 或者 DCUI 进到设备里。我在真实环境里见过的触发原因五花八门有一台是vmdird-syslog.log一晚上涨了 30 多个 GB根因是某个外部系统在高频做 LDAP 查询还有一台是vpxd.log因为反复重连一台存储设备日志里刷了几百万行超时记录最离谱的一次是vsphere-client的日志目录被某个前端异常刷爆。共同点是根因都不在日志本身但先要解决的恰恰是日志本身因为空间不腾出来你连排查根因的工具都用不了。1.2 三分钟定位df、du、find 三板斧进到 vCenter 的 Shell先在 VAMI 里打开 SSH 和 Bash Shell或者从 DCUI 走第一步永远是看整体空间df -h输出里重点关注这几个挂载点/、/storage/log、/storage/db、/storage/seat、/storage/core、/storage/archive、/storage/updatemgr。VCSA 把这些目录做成了独立分区好处是日志爆了不会直接干掉数据库坏处是分区大小固定的谁爆谁死。确认了是哪个分区满了第二步往下一层找是谁吃掉的du -sh /storage/log/* 2/dev/null | sort -h du -sh /storage/log/vmware/* 2/dev/null | sort -h | tail -20sort -h是按人类可读的容量排序tail -20直接看最大的一批。第二步基本就能锁定到具体组件比如/storage/log/vmware/vmdird或者/storage/log/vmware/vpxd。第三步是精确到文件顺便看看时间find /storage/log -type f -size 500M -exec ls -lh {} \; 2/dev/null-size 500M这个阈值我一般按环境调整大环境放到 1G小环境放到 200M。用find比ls强的地方在于它不受目录层级限制有些组件的日志藏在两三层子目录里du只能告诉你哪个目录大find能直接告诉你是哪个文件大。提示VCSA 里/var/log/vmware通常是指向/storage/log/vmware的符号链接。你在做排查和清理之前先用ls -ld /var/log/vmware确认一下实际指向避免照着旧文档操作却删错了地方。不同版本7.0 与 8.0在个别路径上会有细微差异以你环境的实际情况为准。1.3 为什么日志满能把整个vCenter拖死很多人不理解日志写不进去就不写呗为什么整个管理平台都趴了因为 vCenter 的组件是强耦合的日志写入失败在很多组件里被当成致命错误处理。最典型的是vmdird也就是 vCenter 内置的目录服务。它的日志一旦写失败进程会认为自身状态不可信直接退出它一退出所有依赖认证和清单的服务全部失效。vpxd也一样它跟数据库和目录服务之间要保持长连接连接建立不起来就不断重试重试过程又产生大量日志形成日志撑满 → 服务重启 → 更多日志 → 空间更快耗尽的死亡螺旋几分钟之内就能把剩余空间吃干净。所以处理这类故障动手之前要有心理准备你面对的不是一次简单的删文件而是一个正在自我加速的故障循环。清理顺序和清理范围如果没规划好清完可能比清之前更糟。2. vCenter磁盘分区与日志目录拆解空间到底被谁吃了2.1 默认分区布局与容量参考VCSA 的分区设计是有讲究的理解这套布局后面很多决策就不需要死记了。以我手上几套默认部署的 7.0 和 8.0 环境为例小型部署规格具体数值以你环境的df -h实测为准大致是这样挂载点典型默认容量存放内容满了之后的影响/12GB 左右系统文件、部分系统日志系统命令异常、SSH 登录困难最危险/storage/log10GB 左右所有 VMware 组件日志组件崩溃、服务重启最常见/storage/db10GB 左右内置 PostgreSQL 数据库数据写入失败清单和任务大量报错/storage/seat10GB 左右统计数据库性能数据性能图表异常、统计服务报错/storage/core10GB 左右核心转储文件一般不直接影响服务但不该长期占着/storage/archive10GB 左右轮转压缩后的旧日志日志轮转失败进而影响新日志写入/storage/updatemgr视版本而定更新包缓存补丁安装失败这里要划重点的是/storage/archive。很多人清理完/storage/log之后过几天又满了就是因为/storage/archive也满了导致 logrotate 无法把旧日志压缩归档过去于是在原目录里不断生成新的、旧的又删不掉空间很快又见底。所以清理的时候一定要连/storage/archive一起看。2.2 最容易撑爆分区的几类日志在生产环境里下面这几个目录是我见过出镜率最高的空间杀手按踩坑频率排个序vmdird目录下的vmdird-syslog.log。这个文件是当之无愧的冠军几十个 GB 的案例我见过不止三次。根因通常是外部系统在做 LDAP 轮询或者某个集成平台用错误凭据反复尝试认证。vpxd目录下的vpxd.log。正常情况下它由 logrotate 管着但如果 vCenter 连不上 ESXi 主机、存储反复超时、或者某个插件在疯狂报错它能在几小时内涨到几个 GB。vsphere-client和vsphere-ui目录。前端界面的日志一旦有插件异常或者大量并发操作涨得也很快。analytics也叫 vrops 相关组件、perfcharts目录。性能采集和图表渲染相关的日志采集频率高的时候很能吃空间。/storage/core里的转储文件。这个不算日志但经常和日志问题一起出现因为服务崩溃时会生成转储几个转储文件就能吃掉好几 GB。另外还有一个容易被忽略的systemd 的 journal。它默认可能在/var/log/journal下如果 journald 没配置容量上限长期运行下来也能吃掉几个 GB 的根分区空间。journalctl --disk-usage这条命令能直接看到 journal 占了多少。如果超过 500MB就值得整理一下了。2.3 日志轮转机制logrotate 与组件自带的策略VCSA 的日志轮转主要靠两套机制协同一套是统管全局的logrotate一套是部分组件自己实现的轮转逻辑。logrotate的配置在/etc/logrotate.d/下你会看到一堆vmware-开头的文件ls -l /etc/logrotate.d/ | grep -i vmware这些文件里定义了每个组件的日志轮转规则什么时候轮转按大小还是按天、保留几份、轮转后是否压缩、压缩后放哪里。典型的配置长这样/storage/log/vmware/vpxd/vpxd.log { weekly rotate 4 size 100M compress copytruncate missingok notifempty }这里的几个关键点size 100M表示文件超过 100MB 就触发轮转rotate 4表示保留 4 份历史compress表示历史文件压缩copytruncate相当重要——它表示先复制再清空原文件这样即使进程还持有文件句柄也不会写丢。理解了这几个字段你就知道调优的时候该动哪个参数了。3. 临时止血实录十分钟把vCenter从日志满里拉回来3.1 动手之前必须确认的三件事清理日志这件事最大风险不是清不干净而是清错了。所以正式动手前有三件事必须确认。第一确认根因方向。虽然你没法在空间满的情况下做完整排查但至少可以瞄一眼爆炸性增长的日志文件头尾几行判断是良性刷屏还是真的要出大事tail -100 /storage/log/vmware/vmdird/vmdird-syslog.log head -50 /storage/log/vmware/vmdird/vmdird-syslog.log如果看到的是重复的连接超时、认证失败那基本就是刷屏放心清。如果看到的是数据库异常、磁盘 I/O 错误、证书错误这类信息那就要留个心眼清完之后得专门处理。第二确认当前有哪些服务是活着的service-control --status --all这个命令会列出所有组件服务的运行状态。把输出复制到本地一份因为清完日志重启服务之后你可能会忘记原来哪些服务本来就是停用状态。第三确认快照。如果是生产环境且时间允许在 vSphere 层给 vCenter 虚拟机打一个快照再动手。这一步经常被人嫌麻烦跳过但真出事的时候快照能救你几个小时。注意如果你打算清理的是/storage/db目录下任何看起来像数据库文件的东西立刻停手。那不是日志而是内置 PostgreSQL 的数据库文件删掉等于把 vCenter 打回出厂设置且无法通过单纯重建恢复。清理范围严格限制在日志类文件上。3.2 按优先级清理的具体命令与顺序清理顺序我的习惯是先清最安全、收益最大的再处理次要的。具体分四步走。第一步清/storage/archive里的压缩历史日志。这些是已经轮转归档的旧日志删除对服务运行没有任何影响收益还特别大du -sh /storage/archive find /storage/archive -type f -name *.gz -mtime 3 -delete find /storage/archive -type f -name *.log.* -mtime 3 -delete我一般保留最近 3 天的归档排查近期问题时够用了。如果你的环境有合规要求必须保留更长时间把-mtime 3改成14或者更长但要同步评估归档分区够不够大。第二步清/storage/core里的转储文件。这些文件通常叫core.*或者以组件名加时间戳命名ls -lh /storage/core | head -20确认是转储文件后如果不需要提交给官方做故障分析可以直接清掉。但如果有正在跟进的故障单先把需要的那个文件拷到外部存储再删。第三步清各组件目录下明确过期的大文件。这一步要保守只清.log.1、.log.2.gz这类明确是历史轮转产物的文件find /storage/log/vmware -type f \( -name *.log.1 -o -name *.log.2 -o -name *.log.*.gz \) -delete注意这里我没有用-mtime因为这些历史文件本身就是轮转产物删掉是安全的不管它多新。第四步处理当前正在写入的超大日志文件。这一步才是关键也是最多人做错的地方。3.3 正在被占用的日志怎么清truncate 的正确姿势假设vmdird-syslog.log现在是 25GB而分区只有 10GB——这种单文件比分区还大的情况看起来矛盾其实是因为文件在被持续写入的同时磁盘上还有大量已经删除但句柄未释放的空间。不管哪种情况处理方式都一样不要用rm用truncate。为什么不能用rm因为进程正在往这个文件写数据你rm掉之后目录里确实看不见了但进程持有的文件句柄还在磁盘空间依然被占用直到进程关闭这个句柄或者重启。于是你会看到一个诡异的景象ls看不到文件df却一点空间都没释放。更麻烦的是你可能会以为清理失败然后反复操作最后把环境搞得更乱。正确做法是清空文件内容但保留文件本身truncate -s 0 /storage/log/vmware/vmdird/vmdird-syslog.logtruncate -s 0把文件大小设为 0进程原来的文件句柄依然有效会继续往这个空文件里写磁盘空间立刻释放。如果环境里没有truncate命令极少见但 Photon OS 上某些精简环境确实可能没有可以用 shell 重定向: /storage/log/vmware/vmdird/vmdird-syslog.log效果是一样的原理是把文件截断为 0 字节同样保留 inode。清完之后立刻验证df -h du -sh /storage/log/vmware/* 2/dev/null | sort -h | tail -10如果空间没释放说明该文件被某个进程以删除后仍持有的状态占着这时候要用/proc找出来for pid in /proc/[0-9]*; do ls -l $pid/fd 2/dev/null | grep -i deleted; done | head或者如果环境里装了lsof直接lsof L1 | grep -i log找到持有者之后最干脆的办法就是重启对应的服务vmon-cli --restart vmdird重启之后句柄释放空间就回来了。3.4 清理完成后服务拉不起来怎么救清完日志理论上空间够了服务会自己恢复但实际经验告诉我很多时候需要手动拉一把尤其是vpxd和vsphere-ui。我的标准动作是先看状态service-control --status --all如果一堆服务是 stopped不要一个个去起——组件之间有启动顺序依赖顺序错了会反复失败。稳妥的方式是整体重启一遍service-control --stop --all service-control --start --all这个过程会花几分钟vpxd尤其慢它要连数据库、连目录服务、初始化清单。启动过程中可以盯着日志看进度tail -f /storage/log/vmware/vpxd/vpxd.log如果vpxd起不来日志里最常见的是两类错误一类是数据库连接失败通常是因为/storage/db分区也满了或者 PostgreSQL 进程状态异常另一类是认证失败通常是vmdird或者vmafdd还没完全就绪。这时候把这两个服务的日志翻一翻tail -200 /storage/log/vmware/vmdird/vmdird-syslog.log tail -200 /storage/log/vmware/vmafdd/vmafdd.log如果确认是启动顺序问题可以手动按vmdird→vmafdd→vpostgres→vpxd→vsphere-ui这个顺序逐个启动每个服务起来之后再起下一个。最后如果你试了以上所有方法服务依然拉不起来而故障发生的时候你又确实做过一些激进的删除操作那么回到快照或者从备份恢复就是最后的选择。这也是为什么我在 3.1 里把打快照列成必做项。4. 从临时走向半永久轮转调优、扩容与日志外发4.1 调整轮转参数让日志涨得慢一点临时的清理只能解决当下真正减少复发频率要靠调参。这一步不需要动核心配置风险可控收益明显。先看一下当前各个组件的轮转阈值grep -E size|rotate|maxsize|daily|weekly /etc/logrotate.d/vmware-*如果你发现某个组件的size设得特别大比如 500M 甚至 1G而它的日志又是爆炸式增长的那就把它调小cp /etc/logrotate.d/vmware-vpxd /etc/logrotate.d/vmware-vpxd.bak vi /etc/logrotate.d/vmware-vpxd把size 500M改成size 100Mrotate 10改成rotate 5。改完先干跑验证语法别直接生效logrotate -d /etc/logrotate.d/vmware-vpxd-d是 debug 模式只打印它打算做什么不会真的执行。确认没有语法错误、动作符合预期之后再强制跑一次logrotate -f /etc/logrotate.d/vmware-vpxd注意/etc/logrotate.d/下这些vmware-*文件是组件自带的VCSA 升级的时候有概率被覆盖回默认值。所以调完之后要记一笔下次升级完成后复查一遍。这是踩过坑的经验——有一次升完级之前调优的参数全被刷回去了一个月后日志又满了。还有一个更根本的方向是降低日志级别。如果某个组件的日志里 90% 都是重复的 INFO 级别记录那把它调到 WARN 级别日志量立刻降一个数量级。VCSA 各组件日志级别的调整方式不统一有的在配置文件里改有的需要走 VAMI具体到你的环境要翻对应组件的说明别照搬别人的路径。4.2 VAMI里把日志分区扩起来如果环境是长期运行的且storage/log分区空间本来就是按最小规格划的那最省心的办法是给它扩容。前提条件是 vCenter 虚拟机所在的存储有空间。步骤如下先在 vSphere 层给 vCenter 虚拟机的硬盘扩容VCSA 的磁盘通常是多块虚拟磁盘拼起来的扩容时要注意扩的是承载目标分区的那一块然后在 VAMIhttps://vcenter-ip:5480里登录进入监控→磁盘找到对应分区调整大小。这一步有几个坑要提前知道。第一VAMI 里调整分区大小会触发底层的分区操作虽然过程一般不需要重启 vCenter但期间管理界面会有短暂不可用建议放到维护窗口做。第二扩展只能往大了调不能缩小所以别一冲动扩到很大按实际增长速率估算就行——我一般按过去三个月的最大日志量乘 1.5 来定。第三扩容操作前务必确认虚拟机上没有残留的快照有快照的时候做磁盘扩容容易出问题。4.3 日志外发与容量预警把被动变主动比扩容更彻底的方案是把日志外发到独立的日志服务器本地只留很短的保留期。VCSA 7 和 8 都支持配置 syslog 转发可以在 VAMI 的系统→日志转发里配置也可以直接改配置文件。cat /etc/vmware-syslog/vmsyslog.conf配置好转发之后本地日志的保留策略就可以收紧日志分区压力大幅下降。同时外部日志平台还能做集中检索排查效率比 SSH 上去 grep 高得多。预警这块也别落下。VAMI 自带磁盘告警但默认阈值比较宽等它报警的时候往往已经来不及了。我的做法是两条腿走一条是在外部监控平台对 vCenter 的这几个分区做容量采集阈值定在 75% 和 90% 两档另一条是写个简单的定时脚本每天跑一次把大文件清单发到自己邮箱。#!/bin/bash THRESHOLD80 df -h | awk NR1 {gsub(%,,$5); if ($5$THRESHOLD) print $0} du -sh /storage/log/vmware/* 2/dev/null | sort -h | tail -5这个脚本短短几行跑起来放到 cron 里每天执行一次输出重定向到邮件或消息通知就能在问题爆发前拿到信号。我给自己管的几套环境都加了这一层实话说加上之后我再没在半夜被日志满叫起来过。5. 高频问题速查与踩坑清单5.1 常见故障速查表处理 vCenter 日志问题这些年遇到的症状其实高度集中。我把它们整理成一张表方便对着现象直接找处理动作现象大概率原因处理动作df显示/storage/log100%服务大面积 stopped单一组件日志爆炸定位最大文件truncate清空重启对应服务清完文件但df空间没变文件被进程持有句柄未释放用/proc或lsof L1找持有者重启该服务/storage/archive也满了归档保留策略过宽清理过期.gz和.log.*文件收紧轮转保留份数vpxd起不来日志报数据库连接失败/storage/db分区空间不足或 PostgreSQL 异常检查/storage/db空间必要时重启vpostgres登录界面正常但登录报认证错误vmdird或vmafdd未就绪按vmdird→vmafdd→vpxd顺序逐个启动根分区/缓慢增长systemd journal 无上限journalctl --vacuum-size500M并配置SystemMaxUse性能图表无数据/storage/seat分区满检查该分区清理统计数据库旧数据需谨慎操作清理后几天又满根因未处理日志仍在高速增长分析日志内容找根因同时收紧轮转阈值5.2 我踩过的几个坑你最好别踩坑一用rm -rf删日志目录。早年间有一次急着腾空间直接rm -rf /storage/log/vmware/vmdird/*结果目录被删掉了vmdird重启时因为目录不存在直接启动失败还得手动重建目录并修正权限多花了半小时。记住删文件不删目录实在要删目录先确认权限和属主。坑二清完不验证直接走人。有一次清完日志看到空间恢复了就下班了第二天发现vpxd一直在重启。原因是清的时候顺手删了一个正在被vpxd读取的配置文件文件名里带.log实际是配置。所以清理时严格按文件名后缀过滤清完必须跑一遍service-control --status --all确认所有应该运行的服务都在运行。坑三忽略/storage/core。这个分区经常被遗忘因为它的文件不叫.log。但服务崩溃一次产生的转储能占几百兆到几个 GB几次崩溃下来就能把分区填满。而且它满了之后不一定会立刻报错属于慢性病。坑四在业务高峰期做整体重启。service-control --stop --all会让整个 vCenter 管理面下线期间所有依赖 vCenter 的自动化平台、备份任务、监控采集全部失败。这个操作一定要放到维护窗口或者至少提前通知相关方。5.3 临时方案的风险边界与后续动作最后说清楚一件事这篇文章讲的清理手段本质都是止血不是治病。它们能让你在十分钟内把 vCenter 从崩溃边缘拉回来但没有解决为什么日志会涨这么快这个问题。所以清理完成、服务恢复之后后面还有几件事要做。第一把清空前的日志内容尽可能捞出来分析——如果清理前你截了tail的样本这时候就派上用场了如果没有赶紧看看外部日志平台有没有留存。第二找到根因之后针对性处理比如某个外部系统的高频认证请求要么修正凭据要么调整轮询频率。第三把轮转阈值、分区容量、监控告警这几件事补齐形成闭环。我自己现在的习惯是每次处理完这类故障都写一条记录故障时间、触发分区、最大文件、清理动作、根因、后续改进项。攒上一年你会发现同一个环境里的日志问题其实就那两三个源头把源头掐掉之后这类故障基本就绝迹了。日志本身不是敌人它只是第一个诚实告诉你系统出问题的地方——把日志清干净是必要的但顺着日志找过去才是真正把活干完。
阅读完成 · 觉得有帮助？
