📚 课程目录第3章遥测数据面基础

3. 遥测数据面基础

在Marvell Teralynx、Prestera等交换芯片上做网络遥测，第一步不是写采集脚本，而是判断“哪一类遥测机制能在当前芯片上以线速运行”。INT、IOAM、Postcard、sFlow、IPFIX这五种机制看似都叫“遥测”，但它们在数据面所处的位置、封装方式、采样粒度、对芯片资源的依赖完全不同。选错机制，往往不是功能缺失，而是性能直接掉一个数量级。

五种机制的本质差异

INT（In-band Network Telemetry）属于带内逐跳遥测。报文经过每一跳交换机时，芯片在报文头部插入本跳的元数据，例如入端口、出端口、队列深度、时间戳、拥塞标记。它的关键特征是“随业务报文走”，因此能精确反映某一条流的真实路径状态。代价是报文变长，且需要芯片支持可编程解析与插入逻辑。

IOAM（In-situ OAM）是INT的标准化版本，定义在RFC 9197中，使用IPv6或NSH承载，字段结构更规范，支持逐跳和端点两种模式。IOAM的优势是跨厂商互操作，但在Marvell平台上，其支持程度取决于芯片是否具备对应的可编程流水线以及软件是否已实现IOAM封装模板。

Postcard是Marvell平台上一类轻量级带内遥测机制，通常以固定长度的小报文或元数据尾随方式，把关键跳数信息压缩后发送到采集器。它不修改业务报文，而是复制或镜像关键元数据，因此对业务流影响小，适合高密度端口场景。Postcard的字段和触发条件通常由芯片的遥测引擎直接生成，软件只需配置采集目标和触发阈值。

sFlow是采样型遥测。芯片按固定采样率（如1/1000）复制报文头部到采集器，采集器据此推断流量构成和路径。sFlow对芯片资源占用低，但它是统计推断，不是逐包精确记录。在Marvell平台上，sFlow通常由硬件采样引擎配合CPU或管理口完成。

IPFIX是流级遥测，基于NetFlow v9演进而来。它不复制报文，而是由芯片或软件维护流表，按流导出统计信息，例如五元组、字节数、包数、时间窗口。IPFIX适合流量分析和计费，但流表容量和老化策略直接影响精度。

Marvell平台上的支持差异

在Marvell Teralynx系列中，INT和IOAM的支持取决于芯片是否具备可编程的解析器与编辑器。Teralynx 7及以上版本通常支持INT元数据插入，但IOAM需要软件栈配合，例如使用P4或SDK中的遥测模板。Postcard在Marvell平台上有专门的硬件遥测引擎支持，配置相对简单，通常通过SDK的遥测API设置采集目标IP、UDP端口和触发条件。sFlow和IPFIX则更多依赖芯片的采样引擎和流表硬件，Prestera系列在这两类机制上支持较成熟。

一个常见的误区是认为“支持”就等于“线速可用”。实际上，INT和IOAM在插入元数据时会增加报文长度，如果芯片的编辑流水线深度不足，可能触发慢路径或丢包。Postcard虽然不修改业务报文，但复制元数据同样消耗内部带宽，高密度端口下需要评估遥测引擎的吞吐上限。sFlow和IPFIX的采样率或流表容量设置不当，会导致采集器收到大量重复或缺失数据。

选型依据与决策路径

选型时先问三个问题：第一，需要逐包精确路径还是统计趋势？第二，业务报文能否接受变长？第三，芯片资源是否允许开启可编程流水线？如果答案是“逐包精确路径”且“能接受变长”，优先INT或IOAM；如果“不能修改业务报文”但需要逐跳信息，选Postcard；如果只需要流量构成和趋势，选sFlow；如果需要流级计费和长期分析，选IPFIX。

在Marvell平台上，还有一个实际约束：不同芯片型号的遥测引擎能力不同。例如，Teralynx 9支持更深的INT元数据栈，而Prestera系列可能只支持固定格式的Postcard。因此，选型前应查阅对应芯片的SDK文档，确认遥测功能的可用性和性能边界。

实操建议：在实验室环境中，先用小流量验证INT/IOAM的插入是否正常，检查报文长度和校验和；再用高密度端口测试Postcard的复制吞吐；最后用sFlow和IPFIX对比同一流量的统计差异。记录每种机制在芯片上的CPU占用、内存消耗和丢包率，作为选型依据。

配置示例：Postcard触发条件

以下是一个Postcard遥测引擎的配置片段示例，用于在检测到队列深度超过阈值时触发元数据复制：

telemetry postcard profile PC_QUEUE_DEPTH
  trigger queue-depth threshold 80%
  metadata ingress-port, egress-port, queue-id, timestamp
  collector ip 192.168.10.50 port 9995
  sample-rate 1
  enable

该配置表示：当队列深度超过80%时，芯片复制入端口、出端口、队列ID和时间戳，发送到采集器192.168.10.50的9995端口。sample-rate为1表示每个触发事件都上报，若设为10则每10个触发事件上报一次。实际参数需根据芯片SDK的语法调整。

结果判读与常见问题

开启遥测后，应观察三个指标：采集器收到的元数据条数是否与预期触发次数一致；业务报文的转发时延是否增加；芯片的遥测引擎是否出现溢出计数。如果元数据条数远小于触发次数，可能是采样率设置过低或遥测引擎带宽不足。如果业务时延明显增加，可能是INT/IOAM的插入操作进入了慢路径。如果遥测引擎溢出计数持续增长，需要降低采样率或减少元数据字段。

在Marvell平台上，还可以通过SDK的调试命令查看遥测引擎的状态，例如show telemetry engine stats，确认复制队列的深度和丢弃计数。这些数据是判断选型是否合理的关键依据。

注意：INT和IOAM的元数据插入会改变报文长度，若路径中存在MTU限制，可能导致报文被丢弃。部署前应确认全网MTU一致，或在芯片上配置分片处理策略。

总结来说，五种机制没有绝对优劣，只有是否匹配当前场景。在Marvell平台上，先确认芯片能力，再根据精度需求、报文影响和资源开销做取舍，才能让遥测数据真正服务于网络健康诊断。