2. 网络故障诊断的数据基础

网络故障自动诊断系统的能力上限，首先由它能看到什么数据决定。一个只能读取接口 up/down 状态的系统，最多只能判断链路是否断开；而一个同时掌握 SNMP 计数器、Syslog 事件、NetFlow 会话、gNMI 配置状态和 Telemetry 高频指标的系统，才有可能区分“链路真的断了”和“链路没断但丢包严重”。因此，理解各类数据源的特点、采集方式和标准化方法，是构建诊断能力的第一步。

六类核心数据源及其诊断价值

SNMP 是最传统的网络管理协议，通过 OID 树读取设备的管理信息库（MIB）。它的优势在于覆盖面广、几乎所有网络设备都支持，适合采集接口状态、CPU/内存利用率、接口错包计数等中低频指标。典型采集周期为 30 秒到 5 分钟。但 SNMP 轮询存在精度不足的问题：如果接口在两次轮询之间发生瞬时拥塞，计数器差值可能被平均掉，难以还原真实峰值。

Syslog 是设备主动推送的事件日志，包含接口状态变化、协议邻居震荡、认证失败、硬件告警等。它的价值在于“事件驱动”——故障发生时设备会主动上报，不需要轮询等待。但 Syslog 格式因厂商而异，同一类事件在不同设备上的文本描述可能完全不同，必须经过解析和归一化才能用于自动诊断。

NetFlow（及 IPFIX、sFlow）提供流级别的会话统计，记录源/目的 IP、端口、协议、字节数、包数、时间戳等。它回答的是“谁在和谁通信、流量多大、持续多久”，适合定位流量异常、识别异常会话、分析应用性能问题。NetFlow 通常由路由器或交换机采样导出，采样率常见为 1:1000 或 1:100，采样率直接影响分析精度。

gNMI 是面向现代网络设备的 gRPC 管理接口，支持 Get、Set、Subscribe 三种操作。与 SNMP 相比，gNMI 使用结构化数据模型（如 OpenConfig），返回的是带路径的 JSON 或 Protobuf 数据，天然适合程序化处理。Subscribe 模式支持流式订阅，设备在状态变化时主动推送，兼顾了实时性和结构化。

Telemetry 通常指基于 gNMI 或 gRPC 的流式遥测，采集周期可达到秒级甚至亚秒级，适合监控队列深度、时延抖动、微突发等高频指标。它的数据量远大于 SNMP 轮询，需要配套的时序数据库和降采样策略。

API 则包括设备 RESTCONF/NETCONF 接口、控制器北向接口、云平台 API 等，用于获取配置、拓扑、策略等“意图层”数据。诊断时，API 数据帮助判断“配置是否与预期一致”，而 Telemetry 数据帮助判断“实际运行状态是否偏离预期”。

采集方式的选择与组合

采集方式决定了数据的时效性和完整性。轮询采集实现简单、兼容性好，但存在采集间隔盲区；流式采集实时性高，但对设备和采集端都有更高要求；事件接收是被动模式，依赖设备主动上报，可能因网络中断而丢失关键日志。实际部署中通常采用组合策略：用 SNMP 轮询获取基础健康指标，用 gNMI Subscribe 获取关键接口的秒级状态，用 Syslog 接收事件告警，用 NetFlow 补充流量维度。四类数据在时间轴上对齐后，才能形成完整的故障现场还原。

采集频率需要根据诊断目标设定。以接口错包诊断为例，如果只关心“是否有错包”，5 分钟轮询足够；如果要判断“错包是否在特定时间段集中出现”，则需要 10 秒级采集。一个实用的原则是：采集周期应小于故障特征持续时间的一半，否则可能漏采。例如微突发持续时间约 200 毫秒，则采集周期应小于 100 毫秒，这只有 Telemetry 流式采集才能满足。

数据模型与标准化

多源数据最大的问题是“同名不同义、同义不同名”。SNMP 中接口索引是 ifIndex，NetFlow 中接口用 ifIndex 或 SNMP 接口名，Syslog 中可能只写接口描述，gNMI 中则使用 OpenConfig 的 interface name。如果不做标准化，诊断引擎无法把同一物理接口的多个数据源关联起来。

标准化的核心工作包括四步。第一步是字段映射：把各数据源的原始字段映射到统一的数据模型。例如将 SNMP 的 OID 1.3.6.1.2.1.2.2.1.14（ifInErrors）映射为统一指标 interface.in_errors；将 Syslog 中 %LINK-3-UPDOWN 映射为事件码 LINK_STATE_CHANGE。第二步是时间对齐：所有数据统一使用 UTC 时间戳，并记录采集延迟，避免用“设备本地时间”做关联。第三步是实体关联：为每台设备、每个接口、每条链路分配全局唯一标识，通常用 设备管理IP + ifName 或 设备序列号 + 接口索引 作为主键。第四步是数据模型选择：优先采用 OpenConfig 或 YANG 模型，因为它们已经是结构化、可扩展的行业标准；对于厂商私有数据，则建立映射表转换为标准模型。

数据质量与诊断可信度

数据源本身的质量直接影响诊断结论。SNMP 计数器是 32 位或 64 位整数，32 位计数器在高速接口上可能几十秒就回绕一次，必须做回绕检测；Syslog 可能因 UDP 传输丢包而缺失关键事件，需要配合序列号或确认机制；NetFlow 采样率如果设置过高（如 1:10000），小流量异常可能完全不被采样到；Telemetry 数据量过大时，如果采集端处理不过来，会出现数据积压和延迟，反而降低实时性。

因此，在诊断系统上线前，应建立数据质量检查机制：检查各数据源的心跳是否正常、时间戳是否漂移、关键字段是否缺失、计数器是否异常回绕。只有数据可信，诊断结论才可信。一个常见的工程做法是，在诊断引擎入口处设置“数据质量门禁”：当某数据源超过 3 个采集周期无数据时，自动降级该数据源的权重，并在诊断结论中标注“依据不完整”。

从数据到诊断的最小闭环

以“某园区核心交换机下联端口频繁丢包”为例，完整的数据链路是：SNMP 轮询发现 ifOutDiscards 持续增长；gNMI Subscribe 获取该接口队列深度在业务高峰时段达到阈值；Syslog 收到 QOS-3-QUEUE_DROP 事件；NetFlow 显示该接口下联的语音流量占比异常升高。标准化后，四条数据关联到同一接口，诊断引擎输出“队列拥塞导致丢包，建议检查 QoS 策略或扩容带宽”。这个闭环说明：数据源不是越多越好，而是要在标准化后能够相互印证，形成可解释的诊断证据链。

总结来说，故障诊断的数据基础包括三层能力：第一层是“采得到”，即覆盖 SNMP、Syslog、NetFlow、gNMI、Telemetry、API 六类数据源；第二层是“对得齐”，即通过字段映射、时间对齐、实体关联完成标准化；第三层是“信得过”，即通过数据质量检查确保诊断结论可靠。三层能力缺一不可，共同构成自动诊断系统的数据底座。