企业官网建设流程全解析

凌晨两点接到电话，说 vCenter 登不上了，vSphere Client 里所有主机和虚拟机全是灰色的，SSH 敲进去一看，df -h显示某个分区 100%。这种场面做虚拟化运维的基本都遇到过，十次里有七八次就是vCenter 日志满惹的祸。vCenter Server Appliance（VCSA）给日志划的分区是固定的，一旦某个组件开始疯狂刷日志——最常见的几个老熟人就是 vpxd、vmdird、vsphere-ui——分区撑满之后写不进去日志，服务自己就崩了，接着整条管理链路跟着挂。这篇文章不谈理论，就把我这些年处理 VCSA 7.0 和 8.0 日志撑爆时用的临时止血流程完整讲一遍：怎么在三分钟内定位到是哪个目录吃掉了空间、哪些日志能直接清、被进程占用的文件怎么清才真的释放空间、清完之后服务起不来怎么救，以及留在环境里那几个"半永久"的调优动作。内容偏实操，刚接手 VCSA 的新手能照着抄，老手也可以对着速查表核一遍自己的流程。

1. vCenter日志满是什么症状：先看清"病"再动手

1.1 从告警到"服务全趴"的典型演进路径

vCenter 日志满这件事，几乎不会一上来就报"磁盘空间不足"，它是一步一步烂下去的，中间有好几个可以拦截的窗口期，可惜大部分人第一次遇到时都错过了。

第一阶段的信号通常很温和：vSphere Client 登录变慢，操作一台虚拟机要转圈十几秒，任务列表刷新卡顿，性能图表点进去半天不出数据。这时候日志分区大概已经到 85% 到 90% 了，各个服务还在正常工作，只是写日志的 I/O 变慢，间接拖累了整体响应。

第二阶段就开始明显了：某个具体功能报错，比如"无法启动虚拟机"、"无法创建快照"、"清单对象加载失败"，登录时提示认证服务异常。这一步通常是被撑满的那个分区已经到 95% 以上，部分组件的日志写不进去，直接抛异常。

第三阶段是最惨的：vpxd（vCenter 的核心服务）反复重启，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 -20

sort -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实测为准），大致是这样：

这里要划重点的是/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.log

truncate -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 100M，rotate 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 的磁盘通常是多块虚拟磁盘拼起来的，扩容时要注意扩的是承载目标分区的那一块），然后在 VAMI（https://<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 THRESHOLD=80 df -h | awk 'NR>1 {gsub("%","",$5); if ($5>'"$THRESHOLD"') print $0}' du -sh /storage/log/vmware/* 2>/dev/null | sort -h | tail -5

这个脚本短短几行，跑起来放到 cron 里每天执行一次，输出重定向到邮件或消息通知，就能在问题爆发前拿到信号。我给自己管的几套环境都加了这一层，实话说，加上之后我再没在半夜被日志满叫起来过。

5. 高频问题速查与踩坑清单

5.1 常见故障速查表

处理 vCenter 日志问题这些年，遇到的症状其实高度集中。我把它们整理成一张表，方便对着现象直接找处理动作：

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的样本，这时候就派上用场了；如果没有，赶紧看看外部日志平台有没有留存。第二，找到根因之后针对性处理，比如某个外部系统的高频认证请求，要么修正凭据，要么调整轮询频率。第三，把轮转阈值、分区容量、监控告警这几件事补齐，形成闭环。

我自己现在的习惯是，每次处理完这类故障都写一条记录：故障时间、触发分区、最大文件、清理动作、根因、后续改进项。攒上一年，你会发现同一个环境里的日志问题其实就那两三个源头，把源头掐掉之后，这类故障基本就绝迹了。日志本身不是敌人，它只是第一个诚实告诉你系统出问题的地方——把日志清干净是必要的，但顺着日志找过去，才是真正把活干完。