📚 课程目录第3章遥测数据采集机制

3. 遥测数据采集机制

在 Broadcom 交换平台上，遥测数据采集并不是单一技术，而是由多条并行采集通道组成的分层体系。理解这些通道的差异，关键在于回答三个问题：数据在哪里产生、由谁推送、以什么粒度上报。下面按“采样流遥测—流级导出—模型驱动订阅—带内逐跳遥测—本地计数器”的顺序展开。

一、采样类：sFlow 与 IPFIX 的采集原理

sFlow 采用“采样 + 计数器轮询”双通道模型。数据面在入口/出口对报文做固定间隔采样（如 1/1024），把采样报文头部截取后封装成 sFlow Datagram 发往 Collector；同时周期性读取接口计数器。它的优点是开销极低、与转发芯片解耦，缺点是只能看到采样点，无法精确统计每条流的字节数。

IPFIX（NetFlow v10）则基于流表缓存：报文进入后按五元组匹配流表，命中则累加字节数、包数、时间戳，流老化或主动导出时把 Flow Record 发往 Collector。它比 sFlow 精确，但需要芯片维护流表，规模受表项容量限制。两者在 Broadcom 平台上通常由 SDK 的采样引擎和流表硬件共同支撑。

# sFlow 典型配置（示意）
sflow collector 192.0.2.10 6343
sflow agent-ip 192.0.2.1
sflow sampling-rate 1024
sflow polling-interval 30
interface Ethernet1/1
  sflow enable

# IPFIX 典型配置（示意）
ipfix collector 192.0.2.20 4739
ipfix export-protocol udp
flow record FIVE-TUPLE
  match ipv4 source address
  match ipv4 destination address
  match ip protocol
  match transport source-port
  match transport destination-port
flow exporter EXP-1
  destination 192.0.2.20
  transport udp 4739
flow monitor MON-1
  record FIVE-TUPLE
  exporter EXP-1
interface Ethernet1/1
  ipfix monitor MON-1

二、模型驱动类：gNMI 与 gRPC 的订阅机制

gNMI 是 gRPC 之上的网络管理协议，核心是 Subscribe RPC。它支持三种模式：ONCE（一次性拉取）、POLL（按需轮询）、STREAM（持续推送）。STREAM 又分 ON_CHANGE 与 SAMPLE：前者只在状态变化时上报，适合链路 up/down、告警；后者按固定周期上报，适合端口速率、队列深度等连续量。gRPC 提供 HTTP/2 多路复用与 Protobuf 编码，使单连接可承载大量订阅路径。

# gNMI Subscribe 请求（示意，SAMPLE 模式）
subscribe:
  subscription:
    - path: "/interfaces/interface[name=Ethernet1/1]/state/counters"
      mode: SAMPLE
      sample_interval: 10000000000   # 10s，单位纳秒
  mode: STREAM
  encoding: PROTO

配置要点：路径必须与设备 YANG 模型一致；采样周期要与 Collector 处理能力匹配，过密会导致 gRPC 流拥塞；ON_CHANGE 需确认设备支持对应叶子的变更通知。

三、带内遥测：INT 与带内网络遥测

INT（In-band Network Telemetry）让数据包自身携带遥测指令，沿途每跳交换机把本跳的端口、队列、时延、时间戳写入包头，最终由接收端或 Collector 解析。它不依赖额外探测包，能获得逐跳、逐包的精确视图，代价是增加报文长度和芯片处理开销。Broadcom 平台通常通过 INT 元数据封装与解析流水线实现，需在入口定义 INT 头、在每跳插入元数据、在出口剥离并上报。

四、本地计数器：流表、端口与队列统计

流表统计由 ACL/流表硬件维护，每个表项附带包数、字节数计数器，通过 SDK 或 gNMI 读取；端口统计来自 MAC/PCS 层计数器，包括收发包、CRC 错误、丢弃；队列统计来自 TM（流量管理）模块，反映各优先级队列的入队、出队、丢弃和当前深度。这三类数据是健康诊断的“地基”，通常以 gNMI SAMPLE 或 CLI 方式周期采集。

五、采集通道的选择与协同

实际工程中，这些机制并非互斥。典型做法是：用 sFlow 做全局流量画像，用 IPFIX 做关键业务的精确流统计，用 gNMI SAMPLE 采集端口与队列计数器，用 ON_CHANGE 捕获链路事件，用 INT 对特定路径做逐跳时延定位。选择依据是精度、开销、时效三者的权衡：sFlow 开销最低但精度最粗，INT 精度最高但开销最大，gNMI 介于两者之间且最灵活。

配置时注意：sFlow 采样率过高会显著增加 CPU 与带宽占用；IPFIX 流表老化时间过短会导致流记录碎片化；gNMI 订阅路径错误会返回 NotFound，需先用 Capabilities 确认模型版本；INT 需端到端芯片支持，混合厂商环境可能无法解析。

常见误区：把 gNMI 的 SAMPLE 周期设成 1 秒以下，以为“越密越好”，结果 gRPC 流积压、Collector 内存暴涨。建议从 10 秒起步，按业务需求逐步收紧，并监控订阅队列深度。

掌握这些采集机制后，下一步就是把这些数据落到统一的健康诊断模型里：端口统计看物理层，队列统计看拥塞，流表统计看转发行为，INT 看路径时延，sFlow/IPFIX 看流量构成。只有把采集通道与诊断指标对应起来，遥测数据才真正具备工程价值。