📚 课程目录第3章 Catalyst遥测配置入门

3. Catalyst遥测配置入门

Model-Driven Telemetry（MDT，模型驱动遥测）是 Catalyst 9000 上替代传统 SNMP 轮询的核心机制。传统 SNMP 由网管每隔一段时间主动去“问”设备，设备被动应答；MDT 则反过来，由设备按订阅关系主动、持续地把数据“推”给采集器。理解这一“拉”与“推”的差别，是配置前最重要的一步：它决定了数据是周期性快照还是高频流式，也决定了设备与采集器之间谁发起连接、谁监听端口。

在 Catalyst 9000 上，MDT 的数据来源是 YANG 模型，编码格式通常为 JSON 或 GPB（gNMI 场景），传输层可以是 gRPC 或 NETCONF。本节聚焦两种最常用的 gNMI 模式：Dial-in（拨入）与 Dial-out（拨出）。二者最本质的区别在于 TCP 连接由谁发起。

Dial-in 与 Dial-out 的连接方向

Dial-in 模式下，采集器（Collector）作为客户端主动连接交换机的 gRPC 端口（默认 50052 或 57400，取决于软件版本与配置），交换机作为服务端监听。采集器通过 gNMI Subscribe RPC 下发订阅请求，指定路径、采样间隔和编码。Dial-out 模式则相反：交换机作为客户端，主动向采集器地址发起 gRPC 连接，并按本地配置的订阅推送数据。Dial-out 更适合采集器位于防火墙之后、无法被设备主动访问的场景；Dial-in 则更灵活，采集器可随时增删订阅而无需改动设备配置。

Dial-in 配置实操

在 Catalyst 9000 上启用 gNMI Dial-in，首先需要开启 gRPC 服务并指定监听端口。以下为示例配置（参数为教学示例，实际端口与认证方式请以设备软件版本为准）：

! 启用 gRPC 服务，监听 57400 端口
gnmi-yang
gnmi-yang server
gnmi-yang port 57400
!
! 配置 gRPC 认证（可选，生产环境建议启用）
grpc
 grpc tls
  grpc tls certificate trustpoint TP-GNMI
!
! 验证 gRPC 服务状态
show gnmi-yang state
show grpc status

配置完成后，采集器即可通过 gNMI Subscribe 请求订阅接口计数器。一个典型的订阅请求包含以下关键字段：path 指定 YANG 路径，mode 选择 STREAM 或 ONCE，sample_interval 指定采样周期（纳秒），encoding 选择 JSON_IETF 或 PROTO。例如订阅所有接口的入向字节数，路径可写为 /interfaces/interface/state/counters/in-octets，采样间隔设为 10000 毫秒（即 10 秒一次）。

验证 Dial-in 是否成功，最直接的方法是在采集器侧观察是否收到数据流。若使用 gnmic 工具，可执行：

gnmic -a 192.0.2.10:57400 --insecure \
  subscribe \
  --path "/interfaces/interface/state/counters/in-octets" \
  --mode stream \
  --sample-interval 10s \
  --encoding json_ietf

若返回持续刷新的 JSON 数据，说明 Dial-in 链路已通。若连接被拒绝，应检查设备 gRPC 服务是否启动、端口是否被 ACL 拦截、TLS 证书是否匹配。

Dial-out 配置实操

Dial-out 需要在设备上预先定义订阅和目的地。Catalyst 9000 使用 telemetry ietf subscription 与 telemetry receiver 两组配置。以下示例将接口计数器和 CPU 利用率分别推送到采集器的 57500 端口：

! 定义接收器（采集器地址与端口）
telemetry receiver protocol grpc
 address 192.0.2.20 port 57500
!
! 订阅接口计数器
telemetry ietf subscription 100
 encoding encode-json
 filter xpath /interfaces/interface/state/counters
 source-address 192.0.2.10
 stream yang-push
 update-policy periodic 10000
 receiver 192.0.2.20 port 57500
!
! 订阅 CPU 利用率
telemetry ietf subscription 200
 encoding encode-json
 filter xpath /process-cpu/cpu-usage/cpu-utilization
 source-address 192.0.2.10
 stream yang-push
 update-policy periodic 10000
 receiver 192.0.2.20 port 57500

其中 update-policy periodic 10000 表示每 10000 毫秒推送一次，stream yang-push 表示采用 YANG-Push 流式机制。配置完成后，用 show telemetry ietf subscription all 查看订阅状态，用 show telemetry receiver all 查看接收器连接状态。若状态显示 Connected，说明设备已成功向采集器建立 gRPC 会话。

采集接口计数器与 CPU 利用率

接口计数器是判断链路健康度最常用的遥测对象。在 Catalyst 9000 上，Cisco-IOS-XE-interfaces-oper 模型提供了 in-octets、out-octets、in-errors、out-errors、in-discards 等关键字段。通过 10 秒粒度的持续推送，可以快速发现突发丢包或流量异常。例如，若某接口 in-errors 在连续几个采样周期内从 0 跃升至数百，说明物理层或双工匹配可能存在问题。

CPU 利用率则来自 Cisco-IOS-XE-process-cpu-oper 模型，路径 /cpu-usage/cpu-utilization 返回的是百分比数值。建议将 CPU 采样间隔设为 30 秒或更长，避免高频采集本身增加控制平面负担。当 CPU 利用率持续超过 80% 时，应结合进程级 CPU 数据进一步定位是哪个进程占用过高。

实践提示：Dial-in 与 Dial-out 可以同时启用，互不冲突。建议在实验环境中先用 Dial-in 快速验证 YANG 路径是否正确，确认数据内容符合预期后，再迁移到 Dial-out 用于生产采集器。这样能减少因路径错误导致的无效推送。

验证遥测数据流的判断依据

无论采用哪种模式，验证遥测是否真正生效，应关注三个层面：第一，连接层——gRPC 会话是否建立，Dial-in 看采集器是否成功 Subscribe，Dial-out 看 show telemetry receiver all 是否 Connected；第二，数据层——采集器是否收到符合 YANG 路径的 JSON/GPB 负载，字段值是否随时间变化；第三，业务层——接口计数器是否与 show interfaces 命令输出一致，CPU 利用率是否与 show processes cpu 的数值趋势吻合。三层都通过，才能确认遥测链路完整可用。

最后需要留意的是，遥测数据的高频推送会占用一定的 CPU 和带宽资源。在 Catalyst 9000 上，建议从 10 秒或 30 秒的采样间隔起步，观察设备 CPU 和采集器负载后再逐步调整。对于接口计数器这类变化快、体量大的对象，可优先采用 GPB 编码以降低传输开销；对于 CPU 利用率这类变化较慢的指标，JSON 编码已足够且更易读。