NetFlow v9的选项模板与普通数据模板最大的不同，在于字段布局引入了作用域概念。普通模板定义的都是流记录字段，比如源IP、目的端口、字节数、包数等；选项模板则先定义若干作用域字段，再定义若干选项字段。作用域字段告诉采集器这些选项数据属于哪个系统、哪块接口或哪条流，选项字段则承载具体的测量元数据。对于采样场景，作用域通常填System字段，选项数据使用字段类型34表示采样间隔，类型35表示采样算法。

报文头的source_id在NetFlow v9规范中就是观测域标识。一个导出器如果同时监控多台设备或多个采样点，可以为每个观测域分配独立ID。采集器收到选项数据后，先根据报文头source_id区分观测域，再结合作用域字段判断这条选项记录属于哪个范围。也就是说，光有采样间隔数值还不够，必须让source_id与作用域字段的含义对齐，否则采集器无法区分不同采样点的元数据。

选项模板的二进制布局

NetFlow v9的模板报文和数据报文共用相同的头部，头部之后可以跟着若干模板记录或数据记录。头部共20字节，包含版本号、记录数量、系统运行时间、Unix时间戳、序列号和source_id。使用Ruby处理时，可以用pack指令一次打包这些字段。指令nnNNNN表示6个网络字节序无符号整数，前两个16位，后四个32位。

选项模板记录从模板ID开始，模板ID必须大于255。接着是字段总数，例如一个作用域字段System加上两个选项字段采样间隔和采样算法，总数就是3。每个字段用4字节描述，前两字节是字段类型，后两字节是字段长度。System类型为1，长度4；采样间隔类型为34，长度4；采样算法类型为35，长度1。编码时要把作用域字段长度和选项字段长度分别求和，得到数据报文中需要的Scope Length和Option Length。

需要特别注意的是，模板记录只描述字段类型和长度，真正的数值放在数据报文中。数据记录里先出现2字节Scope Length，再出现2字节Option Length，之后才是作用域字段的值和选项字段的值。例如System字段值4字节，采样间隔4字节，采样算法1字节，那么Scope Length就是4，Option Length就是5。

用Ruby打包并发送模板与数据

下面用一个完整示例说明流程。假设采集器地址为192.0.2.10，端口2055，观测域ID为100，采样间隔为1000个包采样一次，采样算法为0表示非概率采样。代码使用标准库socket，不需要额外依赖。

require 'socket'
class NetFlowV9Exporter
  HEADER_FORMAT = 'nnNNNN'
  TEMPLATE_ID = 256
  SYSTEM_FIELD = 1
  SAMPLING_INTERVAL_FIELD = 34
  SAMPLING_ALGORITHM_FIELD = 35
  def initialize(collector_ip, collector_port, observation_domain_id)
    @collector_ip = collector_ip
    @collector_port = collector_port
    @observation_domain_id = observation_domain_id
    @sequence = 0
    @socket = UDPSocket.new
  end
  def send_template
    header = build_header(1)
    template = build_options_template
    @socket.send(header + template, 0, @collector_ip, @collector_port)
  end
  def send_data
    header = build_header(1)
    data = build_options_data
    @socket.send(header + data, 0, @collector_ip, @collector_port)
  end
  private
  def build_header(count)
    @sequence += 1
    [9, count, uptime, unix_secs, @sequence, @observation_domain_id].pack(HEADER_FORMAT)
  end
  def uptime
    (Process.clock_gettime(Process::CLOCK_MONOTONIC) * 1000).to_i % 0xFFFFFFFF
  end
  def unix_secs
    Time.now.to_i
  end
  def build_options_template
    # 字段总数 = 作用域字段数 + 选项字段数
    [
      TEMPLATE_ID,
      3,
      SYSTEM_FIELD, 4,
      SAMPLING_INTERVAL_FIELD, 4,
      SAMPLING_ALGORITHM_FIELD, 1
    ].pack('n*')
  end
  def build_options_data
    scope_len = 4
    option_len = 5
    [
      scope_len,
      option_len,
      1,
      1000,
      0
    ].pack('nnNNc')
  end
end
exporter = NetFlowV9Exporter.new('192.0.2.10', 2055, 100)
exporter.send_template
exporter.send_data

打包选项模板时，数组中的元素依次是模板ID、字段总数以及三个字段的类型和长度。这里全部使用n指令，也就是2字节无符号网络字节序。选项数据的打包要匹配作用域和选项的长度：4字节作用域长度、5字节选项长度，后面分别是System字段值1、采样间隔值1000和采样算法值0。System字段值1在本场景中只是一个示例作用域标识，实际部署时可以按采集器的约定填写设备内部系统编号。

头部中的sys_uptime字段以毫秒为单位记录导出器启动时长，unix_secs字段记录当前时间。采集器会使用这两个字段判断报文延迟，所以不要填固定值。代码中uptime使用了单调时钟，避免系统时间调整导致负数。每次发送报文前递增序列号，可以方便采集器检测丢包。

验证采集结果与调试建议

运行脚本后，可以在采集器端用tcpdump抓包确认报文格式是否正确。例如执行tcpdump -i eth0 -nn udp port 2055 -X，观察前20字节头部version是否为9，count是否为1，source_id是否为观测域ID。也可以使用Wireshark内置的NetFlow v9解析器查看选项模板的展开结果，如果采集器没有显示采样间隔字段，多半是模板报文没有先于数据报文到达。

模板刷新周期一般建议30秒到1分钟发送一次，否则采集器重启后会丢失模板定义，导致后续数据无法解析。实际工程中，可以用定时器同时调度模板发送和数据发送，数据报文可以批量包含多条流记录。选项模板的字段长度必须与数据记录完全一致，尤其是采样算法只需1字节时，如果用N指令打包就会变成4字节，造成Option Length解析错位。

还有一个容易忽略的点：观测域ID必须与采集器配置的源标识匹配。如果修改了source_id，却沿用旧的选项模板，采集器可能会把选项数据归到错误设备。排查时可以先关闭业务流量，单独发送选项模板和数据，确认采集器能读出采样间隔和算法，再逐步接入真实流导出。

与企业级采集器的对接考虑

不同厂商对NetFlow v9选项模板的支持程度不同。有的采集器要求作用域字段必须是System，有的还要求必须同时提供采样间隔和采样算法。发送前最好先查阅采集器文档。如果采集器只识别IPFIX，那选项模板的作用域字段可能需要使用observationDomainId类型，而不是System。NetFlow v9本身没有单独的观测域字段类型，观测域始终由报文头source_id承载，这一点在进行协议迁移时要特别区分。

当导出设备数量较多时，可以为每个设备分配不同的模板ID范围，避免模板ID冲突。模板ID虽然是16位整数，但建议方案中集中管理。同时序列号最好按观测域独立计数，因为观测域ID不同的报文在采集器看来可能来自不同源，序列号混用会造成误判。这些细节虽然不影响模板成功下发，但会直接影响长期运行的监控稳定性。

代码改造上，可以把模板记录与数据记录放在同一个UDP报文中发送，只要头部count字段设置为对应记录数量即可。需要注意UDP报文长度不要超过路径MTU，通常控制在1400字节以内比较安全。选项数据记录本身很小，但如果后续要携带多个接口的采样间隔，一次发出多条选项数据时就需要计算总长度。