用四个 Trace View 读懂 MQTT 流量

当 MQTT 系统的表现不符合预期时，第一个难题往往是不知道该从哪里查起。Mqttable Trace 将实时 MQTT 流量整理成四个各有侧重的 View，帮助你检查单条报文、追踪数值变化、了解 Topic 活动，以及调试 Sparkplug 会话。本章会说明每个 View 能看见什么，以及如何根据问题选择合适的 View。

四个 View，四个问题

每个 Trace View 都用来回答一种不同的 MQTT 流量问题。用 Grid 检查单条报文，用 Stream 追踪数值随时间的变化，用 Topics 了解流量去了哪些 Topic，用 Sparkplug 检查节点、设备、指标与会话。

按问题选择 View

先看问题，不要先看哪种视觉形式更顺眼。问题发生变化时就切换 View，不要强迫一种投影回答所有问题。

Grid：精确报文

**最适合：**协议顺序、报文方向、确认链路、MQTT 属性，以及 Mqttable 实际观察到的精确 Payload。

Grid 显示 Trace 记录的每一条 MQTT 报文。沿一行依次阅读时间戳、客户端 ID、类型、方向、主题、QoS、Retain 与 Payload 或原因。如果紧凑列不够，就打开该行；Message Details 会把选中报文的身份、Topic、Payload、属性和大小放在一起。

123

**常见误判：**Topic Filter 会从可见结果中排除 PUBACK 这类没有 Topic 的报文。这不能证明确认报文缺失。得出“没有出现控制报文”的结论前，先重置 Topic Filter。

**何时切换：**需要看趋势而不是逐条报文时切到 Stream；需要知道每个 Topic 有多少保留行时切到 Topics。

Stream：数值随时间变化

**最适合：**遥测漂移、尖峰、振荡，以及相邻消息之间的字段级变化。

Stream 会主动收窄查看范围。选择一个 Client；Mqttable 从该 Client 收到的 PUBLISH 中提取数值序列。序列标签显示最新值，图表把数值对齐到时间轴，Topic tab 切换当前比较对象，Payload Diff 可用于比较上一条与当前值。

下图的数据来自一条每 300 ms 发送一次的定时消息。它的 JSON Payload Template 会在每次发送时重新生成 temperature、humidity 和 pressure 三个随机值，因此图中正好有三条线，每条线都覆盖至少五分钟、超过 1,000 个采样点。

123

常见误判：

• 某个字段或报文没有出现在 Stream，不代表它没有出现在 Trace。非数值、SEND 行、确认报文和其他控制报文不会变成数值序列。
• 图表只属于当前选择的一个 Client，不会把 publisher 与 subscriber 的观察合并成 Broker 全局指标。
• Payload Diff 比较当前 Topic 序列中的相邻消息；它不是 Schema Diff，也不是与保存基线的比较。

**何时切换：**需要核对 PUBACK、Flag、属性或报文顺序时切到 Grid；需要比较多个 Topic 的流量时切到 Topics；需要理解 Sparkplug 生命周期语义时切到 Sparkplug。

Topics：流量结构

**最适合：**发现高噪声命名空间、判断哪些 Topic 占据了大部分保留流量，以及比较同一 Topic 中的 SEND 与 RECV 行。

Topics 按 Topic 对保留的 Trace 行进行分组。每个分组旁的数字是当前纳入范围的行数，不是 Broker 吞吐量。展开分组会回到原始报文，包括客户端 ID、方向、QoS、Payload 与时间戳。没有 Topic 的 MQTT 报文会进入无主题，而不是被丢弃。

123

常见误判：

• Trace 同时观察到 publisher SEND 与 subscriber RECV 时，一条业务消息出现两行是正常的。分组计数不等于唯一业务事件数。
• 当前窗口含 CONNECT、确认报文或其他控制包时，较大的无主题分组很常见。
• 计数只属于当前保留且经过 Filter 的行，不能证明 Broker 的全部历史流量。

**何时切换：**需要跨 Topic 的精确顺序或 Message Details 时切到 Grid；需要查看某个 Topic 内的数值趋势时切到 Stream。

Sparkplug：重建会话

**最适合：**Sparkplug B 节点生命周期、设备清单、指标 Alias、序列连续性，以及当前 Trace 消息对应的协议 Findings。

Sparkplug 是语义重建，不只是另一种分组。Mqttable 会识别 Sparkplug Topic、解码 Protobuf Payload，并根据 NBIRTH、NDATA、DBIRTH、DDATA 等消息建立节点会话。先看摘要，再阅读选中节点的状态、bdSeq、seq、设备、最近事件、清单与 Findings。

123

常见误判：

• Partial 可能只是因为保留窗口从 BIRTH 消息之后开始。这表示当前 Trace 窗口不完整，并不自动等于 Sparkplug 违规。
• Findings 为零只表示当前窗口没有规则产生 Finding，不是对整个部署的认证。
• 请求 Rebirth 会准备 Rebirth 请求。只有真正发送并观察到后续流量后，才能确认请求成功。

**何时切换：**需要查看事件背后的原始方向、Topic、二进制 Payload 或 MQTT 属性时切到 Grid；需要按流量比较完整 Sparkplug 命名空间时切到 Topics。

Filter、加载与 Trace 范围

Filter 改变的是可见性，不是保留状态。写下结论前，应明确自己检查的 Broker tab、Client 或会话、当前 Filter，以及实际检查的 Trace 窗口。

根据发现采取行动

• **MQTT 洞察：**让 Mqttable 分析当前 Trace 中的协议与流量 Findings。接受某个 Finding 作为结论前，先打开它引用的报文。
• **创建 Replay：**把选中的 Trace 消息转成可重复场景。发送流量前检查 Source Boundary，并先执行 Dry Run。
• **导出 Trace：**保留一个有边界的文件用于复核或交接。先检查 Payload 与属性中是否含凭据、Token、个人数据或生产标识。

每项行动都有自己的来源与安全边界。除非界面明确显示，否则不要假设当前 Filter、选中行或可见图表会自动成为后续行动的范围。

Trace 能告诉你什么

Trace 会显示 Mqttable 记录的 Client 侧 SEND 与 RECV 消息，以及对应的时间戳、报文字段和 Payload。在已加载的行内，你可以用它了解报文顺序、数值变化、Topic 分布和 Sparkplug 重建状态。

但 Trace 本身无法显示：

• Broker 内部路由、鉴权决策、持久化或集群复制；
• 下游服务已经处理或保存收到的消息；
• 保留窗口开始前或捕获停止后发生了什么；
• 网络上存在、但 Mqttable Client 没有观察到的报文。

准确描述你看到的结果：“Mqttable 观察到 subscriber 收到了这条 PUBLISH”符合 Trace 显示的内容；“整个系统已经处理消息”还需要查看下游日志或应用数据。要检查 Client 视角之外的网络报文，请继续阅读 PCAP 分析。

下一步

• Replay：使用明确的 Source Boundary 重现有边界的流量。
• PCAP 分析：检查 Client Trace 视角之外捕获的网络报文。