2. Catalyst遥测数据模型与标准

在传统SNMP轮询体系中，网管站按固定周期向设备发起请求，设备被动应答。这种方式在采集高频指标时会产生明显的CPU与带宽开销，而且不同厂商、不同平台的MIB结构差异很大，跨平台统一分析非常困难。模型驱动遥测（Model-Driven Telemetry，MDT）改变了这一模式：设备按照预定义的数据模型主动、持续地推送数据，采集端只需订阅感兴趣的路径。理解MDT，核心是理解四件事：YANG定义"数据长什么样"，gRPC/gNMI定义"数据怎么传"，NETCONF定义"配置怎么改"，而Catalyst 9000的模型支持决定了"哪些路径真正可用"。

YANG：把设备数据变成有结构的树

YANG（RFC 7950）是一种数据建模语言，它把设备上的配置和状态抽象成一棵层级化的树。树的每个节点都有明确的类型、约束和语义，节点路径用类似文件路径的方式表达。例如接口的入向单播报文计数，在OpenConfig模型下大致对应：

/interfaces/interface[name=Ethernet1/0/1]/state/counters/in-unicast-pkts

这条路径包含几个关键信息：interfaces是顶层容器，interface是列表（list），name是列表的键（key），state表示只读状态数据，counters是计数器容器，in-unicast-pkts是具体的叶子节点（leaf）。YANG中还有几个必须区分的概念：container是纯结构容器，本身不承载值；list是可重复的条目集合，靠key唯一标识；leaf是实际承载数据的末端节点；leaf-list是同类型值的数组。此外，config true/false区分可配置节点与只读状态节点，mandatory、range、pattern等约束决定了合法取值范围。

YANG本身只是"语法和结构"，真正让数据可编码、可传输的是编码格式。同一棵YANG树可以映射为JSON、XML或GPB（gRPC Protocol Buffers）等不同编码。JSON可读性最好，适合调试；GPB是二进制编码，体积小、解析快，适合高频大规模采集。Catalyst 9000在gNMI场景下通常优先使用JSON_IETF或GPB编码。

OpenConfig与原生模型：两套并行的路径体系

Catalyst 9000同时支持两类模型。一类是OpenConfig模型，它是厂商中立的开源模型集，路径以/interfaces/...、/system/...、/network-instances/...等开头，跨厂商一致性好，适合构建统一采集平台。另一类是Cisco原生模型，路径通常以Cisco-IOS-XE-开头，例如Cisco-IOS-XE-interfaces-oper、Cisco-IOS-XE-process-cpu-oper，它覆盖更细、更新更快，能暴露OpenConfig尚未标准化的平台特有指标。

两者的取舍很实际：如果目标是多厂商统一看板，优先用OpenConfig；如果需要某个平台特有的深度指标（如特定ASIC队列丢包、控制平面进程级CPU），原生模型往往是唯一选择。实际部署中常见做法是"OpenConfig为主、原生模型补缺"，但要注意同一指标在两套模型下的路径、单位和语义可能不同，不能简单混用。

gNMI、gRPC与NETCONF的分工

这三者常被混为一谈，实际职责不同。gRPC是Google开源的高性能RPC框架，基于HTTP/2，支持双向流、多路复用和二进制传输，是承载遥测数据的传输层。gNMI（gRPC Network Management Interface）是建立在gRPC之上的管理协议，定义了Capabilities、Get、Set、Subscribe四类操作，其中Subscribe是遥测订阅的核心。NETCONF（RFC 6241）则是更早的模型驱动配置协议，基于SSH/XML，擅长配置下发和事务性变更，但用于高频状态采集时效率不如gNMI流式订阅。

gNMI的Subscribe支持三种模式：ONCE只取一次当前值；POLL由采集端按需拉取；SAMPLE由设备按固定周期推送，是周期性指标采集的主力；ON_CHANGE仅在数据变化时推送，适合事件类、状态翻转类数据，能显著降低无效流量。订阅时还需要指定编码格式、采样间隔和是否携带时间戳。

在Catalyst 9000上浏览模型与查询路径

理论讲完，落到设备上。Catalyst 9000运行IOS-XE，模型浏览和路径查询主要靠几条命令。先确认gNMI/gRPC服务是否开启：

show telemetry ietf subscription all
show gnmi-yang state
show platform software yang-management process

要查看设备实际支持的YANG模型清单，可以用：

show yang-interfaces
show telemetry ietf subscription 101 filter type xpath
show running-config | section telemetry

更实用的做法是直接查询模型树。IOS-XE提供了show telemetry ietf subscription配合filter查看已订阅路径，而浏览可用路径则常借助show platform software yang-management process确认YANG进程状态后，通过gNMI Capabilities获取模型列表。下面是一段用gnmic工具查询Capabilities并订阅接口计数的示例（参数为教学示例，非实测值）：

# 查询设备支持的模型与编码
gnmic -a 10.0.0.1:57400 -u admin -p Cisco123 \
      --insecure capabilities

# 订阅接口入向单播计数，每10秒采样一次
gnmic -a 10.0.0.1:57400 -u admin -p Cisco123 \
      --insecure subscribe \
      --path "/interfaces/interface[name=Ethernet1/0/1]/state/counters/in-unicast-pkts" \
      --mode sample --sample-interval 10s \
      --encoding json_ietf

执行后，采集端会持续收到类似下面的JSON消息（示例数据）：

{
  "source": "10.0.0.1:57400",
  "subscription-name": "default",
  "timestamp": 1710000000000000000,
  "updates": [
    {
      "Path": "interfaces/interface[name=Ethernet1/0/1]/state/counters/in-unicast-pkts",
      "values": {
        "interfaces/interface/state/counters/in-unicast-pkts": 128473
      }
    }
  ]
}

判断订阅是否成功，看三点：一是updates数组是否持续出现新消息；二是timestamp是否递增；三是计数值是否随流量变化。如果长时间没有更新，先检查路径是否拼写正确、模型是否被设备支持，再确认采样间隔是否设置过小导致设备拒绝。

模型选择与订阅参数速查

把这一节串起来看：YANG决定数据结构和路径，OpenConfig与原生模型决定你从哪里取数，gRPC/gNMI决定数据怎么流，NETCONF负责配置侧，而Subscribe模式与编码格式决定采集的效率和可读性。掌握这五者的关系，后续的订阅配置、指标分析和故障定位才有稳固的落脚点。