3. Nexus配置采集与解析
配置合规与变更治理的第一步，是把设备上“当前真实生效的配置”稳定、可重复地采集下来，并转换成可比较、可检索、可审计的结构化数据。如果采集环节不稳定，后续的基线比对、差异检测、合规判定都会失去可信基础。Nexus 平台提供了多条采集通道，它们的能力边界、数据粒度和适用场景差异明显，本节按“通道选择—采集实现—结构化解析—结果校验”的顺序展开。
一、三条采集通道的能力边界
NX-OS 命令行是最直接的通道，通过 SSH 执行 show running-config 可获得完整运行配置文本，通过 show startup-config 可获得启动配置。它的优点是覆盖全面、语义权威，缺点是输出为纯文本，需要自行解析，且大配置下传输与解析开销较高。SNMP 适合采集指标类与部分 MIB 对象，例如通过 SNMPv3 读取接口状态、CPU、内存等，但它并不适合完整配置采集，配置类 MIB 覆盖有限，且难以表达层级化配置结构。NETCONF/RESTCONF 是模型驱动通道，Nexus 9000 在较新版本中支持通过 YANG 模型获取结构化配置，返回 XML 或 JSON，天然适合程序化处理，但需要设备开启相应功能并具备模型支持。
实际工程中常见的组合是：以 NX-OS 命令采集完整配置作为权威基线，以 NETCONF/RESTCONF 采集关键结构化字段用于高频比对，以 SNMP 采集运行状态用于健康度关联。三条通道不是互斥关系，而是按数据用途分工。
二、NX-OS 命令采集的关键细节
直接执行 show running-config 会遇到分页问题，输出被 --More-- 截断。标准做法是在会话建立后先关闭分页：
terminal length 0
show running-config
show startup-config
show version
show interface brief
show vlan brief采集脚本应固定使用 terminal length 0，并在读取时以提示符作为结束标志，而不是依赖固定超时。建议同时采集 show version 与 show interface brief，前者提供 NX-OS 版本与硬件型号，后者提供接口状态快照，二者与配置一起构成“配置+上下文”的完整采集包。采集结果建议按 设备名/时间戳/命令名.txt 的目录结构落盘，便于回溯。
三、NETCONF/RESTCONF 的结构化采集
NETCONF 通过 SSH 子系统 830 端口通信，使用 <get-config> 获取配置数据。以 Python 的 ncclient 为例，采集接口配置的典型调用如下：
from ncclient import manager
with manager.connect(host="10.0.0.11", port=830,
username="netops", password="******",
hostkey_verify=False,
device_params={"name": "nexus"}) as m:
filt = """
<filter>
<System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
<intf-items/>
</System>
</filter>
"""
reply = m.get_config(source="running", filter=filt)
print(reply.xml)RESTCONF 则通过 HTTPS 直接访问 YANG 路径，例如获取接口列表可请求 https://10.0.0.11/restconf/data/Cisco-NX-OS-device:System/intf-items，返回 JSON 结构。相比命令文本，模型驱动通道返回的数据已经带有明确的层级与字段名，解析成本显著降低，但前提是设备版本支持对应 YANG 模型，且采集账号具备相应权限。
四、从文本到结构化数据的解析方法
NX-OS 配置文本的核心特征是缩进层级表达嵌套关系。解析时先按行读取，用缩进深度判断父子关系，再按顶层关键字切分块。例如接口配置块以 interface Ethernet1/1 开头，其下缩进行为该接口的属性。解析后建议输出为统一字段结构，至少包含：设备标识、配置块类型、对象名、属性键、属性值、采集时间。这样后续做基线比对时，可以直接按“对象+属性”定位差异，而不必做全文 diff。
解析过程中有三类常见问题需要处理：一是同一属性在不同版本中写法不同，例如接口描述可能带引号也可能不带，需要在归一化阶段统一去除；二是配置中存在注释行与空行，应在解析前过滤；三是某些配置块存在重复出现的情况，例如多次 ip route，需要按列表而非字典存储，避免覆盖丢失。
五、采集结果的校验与判断
采集完成后不能直接进入比对，应先做完整性校验。可检查以下几点：采集文件是否非空且行数在合理范围；show version 是否成功返回，确认设备可达；关键配置块（如 interface、vlan、router）是否都存在；NETCONF 返回的 XML 是否包含预期节点。若任一校验失败，应标记该次采集为不可信，并触发重试或告警，而不是把残缺数据送入合规引擎。
network-admin 等高权限账号执行日常采集，防止采集脚本被滥用导致配置被修改。把三条通道的采集结果统一落到同一套结构化字段后，配置数据才真正具备可比性。下一阶段的基线比对与合规判定，都建立在本节所描述的采集稳定性与解析准确性之上。