做VMware运维的兄弟对VCF 9.0这个版本应该不陌生。它是VMware Cloud Foundation的最新大版本把计算、存储、网络、云管理全部揉进一套SDDC里统一管。表面上看起来vCenter、NSX、Aria Operations这些组件都还在但管理入口和操作模型已经变了很多。尤其是“操作对象”这个词熟练用vSphere的人第一次切到VCF界面十有八九会懵一下——以前是单个集群、单台主机去点看现在是按工作负载域、按资源对象去看。而跟“操作对象”强绑定的“指标报告”就成了日常运维里最绕不开、也最消耗时间的一件事。我写这篇内容就是想把VCF 9.0环境里围绕操作对象的指标采集、聚合、导出、分发这一整套流程做成自动化分享一套我自己在真实环境里反复打磨过的方案。它不是什么高深的研究课题就是很朴素的运维自动化需求每周定时拉取集群、主机、虚拟机、存储的性能和容量指标生成一份结构化报告推送给需要的人中间几乎不需要人介入。适合正在用VCF 9.0做生产环境运维、被手工报表折磨得够呛的同行参考。我尽量把选型逻辑、脚本细节、踩坑过程都讲透你照着做至少能把“每周一上午花两小时导Excel”这件事彻底终结掉。1. 为什么要把VCF 9.0指标报告做成自动化 —— 需求拆解先别急着写代码。我得先跟你对齐几个概念不然后面所有操作你都会觉得悬浮。1.1 操作对象到底是什么在VCF 9.0的语境里“操作对象”不是某个抽象的管理术语而是指你在平台上能监控、能采集、能操作的所有被管资源实体。按我的习惯会把它分成四类工作负载域级对象比如Management Domain、VI Domain这类逻辑边界VCF把多个vCenter Cluster打包成一个域你在这个层级看的是整体容量和健康度。计算与虚拟化对象vCenter Server、Cluster、ESXi主机、Resource Pool、虚拟机。这是传统vSphere里最熟悉的维度。存储对象Datastore、存储策略、vSAN集群、容量和IO延迟都要在这里看。网络对象NSX分段、Tier-0/Tier-1网关、分布式防火墙规则的状态和流量数据。为什么要区分这四类因为每类对象的指标来源不一样。计算对象的指标可以在vCenter里拉存储对象的指标部分要在vSAN或存储设备侧拿网络对象的指标得从NSX的API出。如果你不做区分直接用vCenter的性能API一把梭出来的报告会缺不少关键信息。1.2 手工报告模式的瓶颈哪条线该自动化我见过太多团队VCF都上了9.0指标报告还在用最原始的方式登录Aria Operations手工选择对象和时间范围导出PDF或Excel再把多个导出文件手工合并成一个汇报材料。这套流程真的能跑但很痛。我把痛点分成三个层次规模痛点当被管对象超过200个节点之后手工导出Aria Operations的报表会非常慢。一个包含50台主机、400台虚机的报告光等导出就要10分钟以上而且数据列经常被截断。时效痛点领导要的是“本周趋势”手工报告往往滞后一到两天。而自动化脚本只要定时任务设置好周一早上8点报告准时躺进邮箱。口径痛点不同人导出来的报告指标口径可能不一样。有人看实际使用率有人看峰值使用率有人看已分配容量。自动化脚本可以把口径固化在代码里避免“这个月报告和上个月对不上”的尴尬。我的分界线很简单如果报告周期短于一周、对象数量超过50个、或者需要把多个域的指标合并到一张表里这三条占任意一条都应该走自动化。占两条以上你还在手工做那纯粹是透支自己的时间。这条分界线我建议你直接抄。2. 技术路线选型三条常见方案怎么选目标清楚了方案就好谈了。VCF 9.0环境下做指标报告自动化大体上有三条路。2.1 三种方案对比我把三条主流路线放在一个表里对比你在实际环境里大概率也就碰到这三个选择。方案优点缺点适合场景PowerCLI脚本原生支持vCenter和VCF模块做成ps1直接跑对vSphere运维最友好依赖Windows环境或PowerShell Core处理表格数据的能力弱跨域合并指标vCenterNSXvSAN要切换多个模块临时采集、单域小型环境REST API Python一次把VCF/vCenter/NSX的API吃透能拿到最多维度的原始数据pandas做聚合分析很强代码跨平台需要处理认证token、分页、限流对不熟悉API的人有学习成本中大型环境、跨域报告、长期自动化的首选Aria Operations开箱报表大数据导出界面操作简单自带很多现成Dashboard支持计划任务触发报告导出定制性差很难把多对象合并成同一张自定义表部署在VCF之上的自带报表对非标准需求经常水土不服指标口径要求简单、只要固定模板的场景额外说一句互联网上常提的Ansible自动化运维、Agent之类的工具在VCF 9.0的指标报告场景里我不推荐。Ansible擅长配置下发和状态巡检而不是时间序列性能指标的采集聚合。指标报告的核心是“时序数据统计分析”Python的pandas在这一层几乎无解。2.2 我的最终选择Python PowerCLI SSH 的混合链路我自己最终落地的方案是一条混合链路Python统一编排PowerCLI按需补位SSH/SFTP做跨平台文件分发。没有全押Python也没有全押PowerCLI。原因很简单VCF 9.0的SDDC Manager API能拿到工作负载域、主机、集群等对象的清单这个接口很干净用Python的requests直接调就行。vCenter的性能指标APIstats在拿到MOR对象列表之后也能返回完整的时间序列数据数据处理用pandas比PowerCLI处理CSV方便得多。这一层用Python是效率最优解。但有些采集动作比如vSAN的健康状态、某些NSX告警详情API文档藏得很深直接调经常遇到权限和请求格式的坑。这个时候先用PowerCLI拿到结果导出成JSON再交给Python做后续分析是最省力的路径。报告分发环节里如果你的自动化采集机是一台Ubuntu而接收方或共享存储是一台Windows服务器就需要SFTP或SSH通道来传文件。这是我在真实环境里绕不开的“Ubuntu传文件到Windows”场景。这条链路的优势在于每一层都可以单独替换。API认证方式变了就改采集函数报告模板要换就只改Excel生成模块文件传输协议要调就换分发模块。模块之间靠明确定义的中间文件打交道而不是硬耦合。这条路我实测在600台虚机、80台主机的环境下全流程跑完只需8~12分钟比手工至少快一个数量级。3. 实操落地从环境准备到完整脚本下面进入正题。我会按“准备环境 → 采集对象清单 → 拉取指标 → 生成报告 → 跨平台分发 → 定时调度”的顺序把整套实现过程完整走一遍。3.1 环境准备与最小权限账号我在Ubuntu 22.04上跑这套自动化Python版本是3.10。需要装的库有这么几个pip3 install requests pandas openpyxl paramiko jinja2requests调VCF和vCenter的REST API。pandas指标数据的清洗、聚合、透视。openpyxl写Excel报告支持图表、样式、多Sheet。paramiko实现SFTP跨平台文件传输Ubuntu采集机 → Windows报告服务器。jinja2如果你不想用Excel想生成HTML邮件正文这个很管用。不是必需但我强烈建议装。账号准备这个环节我踩过一次大坑必须提醒你千万别用vCenter的 administratorvsphere.local 账号去跑脚本。虽然权限够了但这个账号一旦在自动化代码里泄露等于整个SDDC门户大开。正确做法是创建一个只读服务账号在vCenter里分配只读角色在Aria Operations里分配Viewer权限在VCF SDDC Manager里分配View权限。最小权限原则不是安全团队的教条是运维自动化必须有的底线。账号信息也不要明文写死在脚本里。我在环境变量里放或者用一个加密的配置文件存。脚本里这样读import os VCF_HOST os.environ.get(VCF_HOST) VCF_USER os.environ.get(VCF_USER) VCF_PASS os.environ.get(VCF_PASS) VC_HOST os.environ.get(VC_HOST)这个习惯越早养成越好后面做Jenkins或者Cron调度时密钥管理都会顺手很多。3.2 指标数据采集REST API 对象清单流程上我会先把“操作对象清单”拿全这是后面一切指标采集的基础。第一步调VCF的API拿到所有工作负载域和关联的vCenterimport requests import json def get_vcf_domains(): url fhttps://{VCF_HOST}/v1/domains resp requests.get(url, auth(VCF_USER, VCF_PASS), verifyFalse) resp.raise_for_status() return resp.json().get(contents, [])这里有个常量要留意VCF 9.0默认API访问token有效期一般是1800秒。如果脚本运行时间超过这个阈值后半段调用会突然401。我的习惯是拿到token后写一个自动刷新函数每10分钟检查一次。接着是用vCenter的API拉对象清单和指标。vCenter 7之后性能指标走的是/rest/com/vmware/cis/monitoring/perf接口不过更通用的做法是直接用PowerCLI先导出To JSON。为什么我在这里绕一下因为vCenter的API返回的是性能计数器ID你得先去查每个计数器指标的含义再拼成TOKEN去取数值这套流程繁琐程度极高调试一次就够呛。而PowerCLI的Get-VMHost、Get-VM、Get-VMHostsStatistics这些cmdlet封装好了直接导出CSV或JSON给Python处理开发效率翻倍。# 用PowerCLI导出主机性能指标 Connect-VIServer -Server $vcHost -User $vcUser -Password $vcPass Get-VMHost | Select Name, State, ConnectionState, CpuUsageMhz, CpuTotalMhz, MemoryUsageGB, MemoryTotalGB | Export-Csv -Path /tmp/host_stats.csv -NoTypeInformation Disconnect-VIServer -Confirm:$falsePowerCLI导出的CSV进入Python之后我按天做归一化再按周聚合CPU峰值使用率、平均使用率、内存峰值、磁盘读延迟、写延迟、IOPS等一个pandas DataFrame轻松算完。这一步就是纯数据处理网上有很多现成套路。vSAN存储指标和NSX网络指标我走同一个逻辑能API拿就用APIAPI麻烦就先用CLI或PowerCLI把原始数据导出Python统一消费。核心思路是“所有的原始数据都落成CSV/JSON中间文件Python做最终分析”这样采集端和分析端完全解耦。3.3 报告生成与跨平台分发Excel、邮件、SFTP数据聚合完成接下来是把DataFrame变成一份能看的报告。我用openpyxl生成Excel结构是这样的第一个Sheet放“域概览”第二个Sheet放“集群与主机性能Top10”第三个Sheet放“虚拟机资源使用排行”第四个Sheet放“存储容量与延迟”第五个Sheet放“网络流量摘要”。每个Sheet里的数据都是从pandas透视表直接填入。关键代码from openpyxl import Workbook from openpyxl.styles import Font, PatternFill from openpyxl.utils.dataframe import dataframe_to_rows wb Workbook() ws wb.active ws.title 域概览 # 把聚合好的DataFrame写入Sheet for r in dataframe_to_rows(summary_df, indexFalse, headerTrue): ws.append(r) # 加一个简单的单元格样式让标题行突出 for cell in ws[1]: cell.font Font(boldTrue) cell.fill PatternFill(start_colorDDDDDD, end_colorDDDDDD, fill_typesolid)每一行的数据宽度要控制比如虚拟机名称、CPU峰值、内存峰值、磁盘延迟、所属集群这些列超过20列就会把Excel撑得没法看。我在生成之前会用pandas把列重命名成“主机名”“CPU峰值%”“内存峰值%”“读延迟ms”这样的短标题。报告生成完就要处理分发。我实测过三种方式最常用邮件推送用smtplib发HTML摘要Excel附件。HTML摘要用jinja2渲染一个简单的表格模板方便领导在手机上一眼看到关键数据。本地留档按日期命名保存例如report_20250113.xlsx方便追溯历史。SFTP推送到Windows共享服务器这就是热搜词里“Ubuntu传输文件到Windows”的典型落地场景。我用paramiko的SFTP实现import paramiko def sftp_upload(local_path, remote_path, host, username, password): transport paramiko.Transport((host, 22)) transport.connect(usernameusername, passwordpassword) sftp paramiko.SFTPClient.from_transport(transport) sftp.put(local_path, remote_path) sftp.close() transport.close() print(fuploaded {local_path} - {remote_path})这样的好处是公司领导在Windows的文件服务器上直接能看到报告不必进Linux机器用命令行看对非技术背景的同事绝对友好。攻击和调度这块我直接用Linux的crontab。每周一早上7点跑一次大约8点半能出报告。如果你的环境里已有Jenkins也可以包成Pipeline但每周一次的固定报告我真没必要用Jenkins一个cron表达式搞定的事情增加一个重平台反而是负担。提醒一下cron里的环境变量和交互式shell不同python的requests依赖的代理设置要写清楚否则脚本在cron里跑的时候会出现“明明手工能跑定时就不行”的诡异情况。4. 踩坑实录常见问题与排查技巧脚本能跑起来不算完稳定跑半年不出问题才算。这块我把实际运行中遇到的高频问题整理成了速查表你以后遇到类似情况可以直接对着查。4.1 问题速查表现象原因解决思路脚本跑一半突然报401VCF或vCenter的token过期默认有效期内调用超过时长用refresh token定期更新或拆分成短任务多次取token返回的对象列表只有25条API分页未处理Page参数循环拉取直到返回数量小于pagesize指标的时间戳比本地时间偏差8小时API返回的是UTC时间在pandas里统一tz_localize再tz_convert保证报告时间口径一致Excel报告打开时提示文件损坏openpyxl写入时同时操作多个ws导致流未正常关闭确保wb.save()在finally块里执行且文件路径无中文字符用了verifyFalse但requests报SSL错误目标环境启用了自签名证书requests版本较新指定requests.packages.urllib3.disable_warnings()并显式传入verifyFalsecron跑不执行但手工执行正常cron环境变量缺失python命令行路径问题cron里用绝对路径写python和脚本路径并在脚本开头导出PATH拉取大量历史指标时报HTTP 500一次性query的时间区间太长API内存爆掉按天分段拉取每天240个采样点5分钟间隔为一段合并后做周聚合这些坑不是从官方文档翻出来的是我真实环境里被绊倒过的地方。每一条后面都有一次加班调的回忆。尤其是UTC时间偏差那个问题我第一版报告拿到手发现所有趋势图的峰值全部偏移了8小时查了整整一个上午才定位到是时区问题。4.2 我个人几次事故换来的经验除了速查表还有几条更细的经验写在这里供你参考。第一关于采集粒度和报告粒度的匹配。vCenter里性能采集默认间隔是5分钟意味着一天最多288个采样点。但如果你做的是“季度容量趋势”报告没必要按5分钟粒度全量拉取存储开销和API压力都很大。我后来改成近7天报告用30分钟粒度月报用2小时聚合季度报只取日聚合值。这套方案基本能覆盖绝大部分场景而且报告体积小很多生成速度快了四五倍。第二写脚本一定要留运行日志。我在脚本里对每次API调用、每个步骤的完成状态、耗时都记录到run.log里。字段包括时间、调用的URL、HTTP状态码、返回的数据量。排查问题时日志比什么debug工具都好使。没有日志遇到“上周还好好的这周突然没报告”的情况你只能干瞪眼。第三报告里的指标口径要单独写一个说明文件。比如“CPU使用率”在报告里究竟是指平均使用率还是峰值使用率“容量”是已分配容量还是实际已用容量这些在Excel里完全不直观。我在报告末尾加了一个“指标口径说明”隐藏Sheet领导问起来直接把Excel甩给他看。省掉了太多解释成本。第四绝对不要在生产上试跑第一版脚本就做大范围批量拉取。先在测试域里跑通一个集群两条指标确认数据准确了再扩展到全量。我那次直接全量拉取vSAN指标把存储API整到超时生产环境监控一度中断虽然后来恢复了但那个教训足够我记一辈子。5. 把这套机制扩展成自动化平台在基础脚本跑顺之后我建议你再往前迈一步把“脚本”变成“平台化工具”。这一步不一定急但方向比我现在做的多出很多可能性。5.1 用pytest把采集脚本变成可回归的自动化测试指标报告最怕的问题就是“改了模板之后老数据对不上”。我在第二版就引入了pytest做回归测试。核心思路是写几种固定的测试用例每次改代码后跑一遍确保核心指标函数输出不变。比如测试“周聚合函数”的输入输出是否一致def test_weekly_aggregation(): raw_data load_sample_csv() expected_peak 86.5 actual_peak weekly_peak_cpu(raw_data) assert abs(actual_peak - expected_peak) 1e-6这个习惯坚持下来半年后迭代版本从1.0到2.3几乎没有因为改代码影响过线上报告。这算是自动化环节里容易被忽略但极其有价值的一步。5.2 调度、日志、告警的闭环自动化平台不能“只管生成报告”还要管“没生成报告的告警”。我用一个很轻量的方式实现这个闭环在cron跑完所有任务后追加一个check_report_exists.py的脚本它检查当天的报告文件是否生成成功、文件大小是否大于某个阈值比如100KB、Excel里的Sheet数量是否等于预期值。如果失败就调用企业微信或钉钉机器人webhook推送一条告警。这样即使脚本半夜挂了你早上起床第一眼就能知道而不是等领导来问“今天的报告呢”才发现。日志统一输出成JSON结构按天归档。走到这一步你手里这套东西已经不是“每周跑一次的小脚本”而是一个有监控、有告警、有回归测试的迷你自动化平台。后续如果团队预算充足可以直接把它包装成Jenkins Pipeline在同一个仪表盘上同时管多个域的指标报告任务。结尾我最后的体会是这类运维自动化工程真正难的不是第一次跑通而是让它稳定、口径清晰、可追溯。报告为别人而写但其价值在它持续、准确地输出让人放心依赖。运营这个系统时我最大的感受是“把重复劳动交给机器把时间留给自己去处理真正重要的故障和规划”。最后再分享一个小技巧给你的报告文件名加上“报告周期”和“生成耗时”。一份10分钟完成、2.3秒生成的周报告能让所有用报告的人对齐时间的信任感。