1. Broadcom交换平台遥测与健康诊断工程导论

在数据中心网络里，交换芯片长期扮演“沉默的高速公路”角色：它每秒转发数以亿计的报文，却很少主动告诉运维人员自己此刻的状态。传统监控依赖 SNMP 轮询接口计数器、CPU 利用率和链路 up/down 事件，采样周期通常是 30 秒到 5 分钟。当一条 400G 链路上出现微突发、缓存瞬时溢出或 ECN 标记激增时，这些事件往往在两次轮询之间发生又消失，等运维人员看到曲线时，问题已经过去，留下的只有业务侧偶发的重传和时延抖动。Broadcom 交换平台遥测与健康诊断工程，正是为了解决“看不见的瞬间”而建立的一套从芯片内部到上层分析系统的完整可观测性体系。

遥测与健康诊断的定义边界

在本课程中，遥测（Telemetry）指交换芯片与平台主动、持续、结构化地输出运行状态数据的能力，强调“推”而非“拉”，强调高频率、细粒度、可编程。它包含三类典型数据：一是流级与队列级的计数与延迟信息，如每队列的入队/出队字节数、缓存占用、排队时延；二是事件与状态信息，如 PFC 帧统计、ECN 标记计数、丢包原因分类；三是芯片内部健康指标，如温度、电压、SerDes 误码率、内存 ECC 纠错计数。

健康诊断（Health Diagnostics）则是在遥测数据基础上，对“平台是否处于健康状态、异常发生在哪一层、是否需要干预”做出判断的过程。它不只是看单个计数器是否超阈值，而是结合基线、趋势、关联关系和拓扑位置，区分正常波动与真实故障。例如，某端口 CRC 错误计数缓慢增长，可能是光模块老化；若同一 SerDes lane 的误码率与温度同步上升，则更可能是散热或供电问题。遥测提供“事实”，健康诊断提供“结论”。

在数据中心网络中的价值

数据中心网络的典型特征是东西向流量占主导、链路速率高、业务对时延和丢包极度敏感。遥测与健康诊断的价值体现在三个层面。

• 故障定位从“小时级”压缩到“分钟级”：当业务反馈跨机架访问变慢时，传统方式需要逐跳登录设备、比对接口计数，耗时且容易遗漏。借助流级遥测，可以直接定位到某台 Leaf 的某个上行队列在特定时间段出现持续排队，进而判断是 ECMP 哈希不均还是对端 Spine 拥塞。
• 从“事后救火”转向“事前预警”：SerDes 误码率、FEC 纠错计数、光模块收发光功率等指标具有明显的劣化趋势。通过持续采集并建立基线，可以在链路真正 down 之前发现劣化，提前安排更换或倒换。
• 为网络调优提供数据依据：PFC 死锁、ECN 阈值设置不合理、缓冲区分配不均等问题，往往在压力测试中才暴露。遥测数据可以量化这些机制的触发频率和影响范围，使调参从经验驱动变为数据驱动。

整体技术栈概览

Broadcom 交换平台的遥测与健康诊断并非单一功能，而是一条从芯片到应用的纵向技术栈。理解这条栈的分层关系，是后续各章节展开的基础。

最底层是芯片内建遥测引擎。以 Trident、Tomahawk 系列为代表，芯片内部集成了计数器阵列、时间戳单元、采样与镜像模块，以及用于缓存和队列状态观测的硬件资源。这些资源通过寄存器或专用通道暴露给上层软件。

其上是数据采集与导出层。常见方式包括：基于 SDK 的寄存器读取、gNMI/gRPC 流式订阅、INT（In-band Network Telemetry）在数据面携带遥测信息、以及 sFlow/NetFlow 等采样导出。不同方式在频率、粒度、对转发性能的影响上差异明显，需要根据场景选择。

再往上是数据管道与存储层。高频遥测数据量巨大，通常先经过消息队列（如 Kafka）缓冲，再写入时序数据库或列式存储。这一层的关键是保证时间戳对齐和标签（设备、端口、队列、流）完整，否则后续关联分析无法进行。

最上层是分析与诊断应用层。包括阈值告警、趋势预测、根因分析、可视化仪表盘和自动化闭环。健康诊断的规则和模型在这一层落地，例如“同一端口 PFC 暂停帧速率超过 X 且持续 Y 秒，同时队列深度超过 Z，判定为拥塞风险”。

从“能看”到“能判断”：一个教学示例

为了把抽象概念落到具体参数上，这里给出一个合理假设的教学示例。某数据中心一台 64×400G 的 Leaf 交换机，运维人员发现业务侧偶发时延抖动。传统 SNMP 每 60 秒采集一次接口计数，曲线平稳，无法解释问题。启用队列级遥测后，以 100ms 粒度采集每个端口的队列深度和排队时延，观察到如下现象：

端口 Eth1/49（上行至 Spine）
  队列 Q3（对应业务 A 的 DSCP 标记）
  时间窗口 14:23:05.100 ~ 14:23:05.800
  队列深度峰值：1.8 MB（基线 0.2 MB）
  排队时延峰值：420 us（基线 35 us）
  ECN 标记计数增量：12,400
  PFC 暂停帧增量：0
  同端口其他队列：正常

这组数据说明：拥塞集中在 Q3，且 ECN 在积极标记但未触发 PFC，说明缓冲区尚未耗尽，属于可恢复的拥塞。进一步关联流级遥测，发现该队列中某条 TCP 流的发送速率在 14:23:05 突增到 38 Gbps，远超其公平份额。诊断结论是：该流未正确响应 ECN，导致队列被短暂占满。处理方式不是扩容链路，而是检查该主机的拥塞控制算法和 ECN 响应配置。如果没有队列级遥测，这个结论几乎不可能在分钟级得出。

本课程的学习路径

后续章节将沿着这条技术栈逐层展开：先理解 Broadcom 芯片提供了哪些遥测原语和寄存器资源，再学习如何通过 SDK、gNMI、INT 等方式把数据取出来；然后讨论数据管道的设计取舍，包括采样率、聚合方式和存储成本；最后进入健康诊断的规则设计、基线建立、异常判定和自动化响应。每一层都会给出可操作的参数、配置片段或判断依据，而不是停留在概念介绍。

需要特别强调的是，遥测与健康诊断不是“装一个工具”就能解决的问题。它要求工程师同时理解芯片行为、协议机制和数据分析方法。例如，看到 PFC 暂停帧计数上升，既要知道这是链路层流控的正常反应，也要判断它是否已经影响到上层业务，还要能区分是偶发突发还是持续拥塞。这种跨层的判断能力，正是本课程希望建立的核心能力。