📚 课程目录第2章 Infinera网元管理接口与数据采集

2. Infinera网元管理接口与数据采集

Infinera开放光网络设备对外暴露的管理接口并非单一协议，而是按“配置下发、状态读取、告警上报、性能采集”四类需求分层组合。理解每种接口的定位，是后续故障诊断与自动化运维的基础。本节围绕SNMP、NETCONF/YANG、RESTCONF、gRPC四类接口，说明它们在Infinera设备上的典型应用场景、数据采集方法与工具选择。

一、四类接口的定位与分工

SNMP是Infinera设备上历史最久、覆盖最广的接口，主要用于告警（Trap/Inform）和性能计数器（MIB OID轮询）。它的优势是网管平台兼容性好，缺点是配置能力弱、批量操作效率低。NETCONF/YANG是当前Infinera网元配置管理的主力接口，基于SSH传输，使用XML编码，支持<get-config>、<edit-config>、<commit>等操作，配合YANG模型可实现事务性配置和候选配置校验。RESTCONF是NETCONF的HTTP化封装，使用JSON/XML，适合与上层编排系统、Web工具集成。gRPC则用于高频、大吞吐的流式遥测（Telemetry），典型场景是秒级性能数据推送，替代传统SNMP轮询。

四类接口不是替代关系，而是互补关系。实际运维中常见组合是：SNMP接收告警Trap，NETCONF做配置变更，gRPC订阅性能流，RESTCONF供第三方系统查询状态。

二、SNMP告警与性能采集

Infinera设备支持标准MIB-II和私有INFINERA-MIB。告警采集通常采用Trap方式：在网元侧配置Trap目的地址和Community，当告警产生或清除时，网元主动向管理站发送Trap PDU。管理站需解析Trap中的sysUpTime、snmpTrapOID和varbind列表，提取告警级别、告警类型、对象标识和发生时间。

性能数据采集则采用轮询方式。以光功率为例，管理站周期性读取ifInOctets、ifOutOctets或私有OID，计算速率和增量。轮询周期通常设为5分钟或15分钟，与网元性能桶对齐。需要注意的是，SNMP轮询频率过高会增加网元CPU负担，建议单网元并发轮询不超过3个会话。

# 示例：使用snmpwalk采集Infinera设备光功率OID
snmpwalk -v2c -c public 192.168.10.21 \
  1.3.6.1.4.1.8709.1.2.1.1.5

# 示例：接收Trap并打印varbind
snmptrapd -f -Lo -c /etc/snmp/snmptrapd.conf

三、NETCONF/YANG配置与状态查询

NETCONF是Infinera设备配置管理的核心接口。设备内置YANG模型库，覆盖端口、交叉连接、光层参数、保护组等对象。一次典型的配置变更流程为：建立SSH会话 → 锁定候选配置 → 编辑候选配置 → 校验 → 提交 → 解锁。候选配置机制允许在提交前进行语法和语义校验，避免错误配置直接生效。

状态查询使用<get>或<get-config>操作，配合XPath或子树过滤，可精确获取指定端口或指定参数。例如查询某端口的光功率和告警状态，可构造如下RPC：

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>optical-1/1/1</name>
        </interface>
      </interfaces>
    </filter>
  </get>
</rpc>

实际运维中，建议使用ncclient（Python库）或netconf-console工具封装会话管理，避免手工拼接XML。对于批量配置，可使用<edit-config>的operation="merge"或operation="replace"属性控制合并策略。

四、RESTCONF与gRPC的适用场景

RESTCONF将YANG模型映射为HTTP资源路径，使用GET/PUT/POST/PATCH/DELETE方法操作。它适合与上层编排系统集成，例如通过GET /restconf/data/ietf-interfaces:interfaces获取接口列表，返回JSON格式。RESTCONF的优点是调试方便，可直接用curl或Postman测试；缺点是事务性弱于NETCONF，不适合复杂配置变更。

gRPC Telemetry用于高频性能数据采集。Infinera设备支持Dial-in和Dial-out两种模式：Dial-in由采集器主动订阅，Dial-out由网元主动推送。订阅时需指定采集路径、采样周期和编码格式（通常为JSON或GPB）。典型采样周期为1秒至10秒，适合监控光功率瞬变、误码突发等快速变化事件。

# 示例：使用gRPC客户端订阅光功率流
python3 telemetry_client.py \
  --target 192.168.10.21:57400 \
  --path /interfaces/interface/optical-power \
  --period 5000 \
  --encoding json

五、采集工具与数据落地

实际工程中，建议按数据类型选择工具链：告警用SNMP Trap接收器（如snmptrapd、Zabbix SNMP Trap），配置用NETCONF客户端（ncclient、Ansible netconf模块），性能用gRPC采集器（Telegraf、自定义Python脚本），状态查询用RESTCONF（curl、Postman）。采集到的数据应统一写入时序数据库（如InfluxDB、Prometheus）或告警平台，便于关联分析和历史回溯。

实践建议：首次接入Infinera网元时，先用RESTCONF或NETCONF的<get>操作确认YANG模型路径和可用参数，再编写采集脚本。避免直接依赖文档中的OID或路径，因为不同软件版本的模型可能存在差异。

注意：SNMP Community和NETCONF/RESTCONF账号应使用只读权限进行数据采集，配置变更使用独立的高权限账号。gRPC Telemetry订阅前需确认网元侧已启用Telemetry服务并配置了采集器白名单。

掌握四类接口的分工与采集方法后，下一步需要建立统一的采集框架，将告警、性能、配置数据关联到同一网元对象上，为后续故障诊断提供完整的数据基础。