如图可见，用户2105122 即使主播又是观众。所以，既有推流身份，又有拉流身份。

我们将时间段，选择到问题时间段。

并且查看自己作为发送端视角，（也就是自己推流的视角）。

发现自己在21:10这个时间段音频上行丢包率高。造成的卡顿。

我们再查看这个时间段的拉流端视角，（也就是观众视角）接收2257462用户发生了卡顿。

但是作为拉流用户，接收其他用户并未发现卡顿。说明仅仅是接收2257462用户出现了问题。

那我们接下来，点击【选择发送端查看详情】看看用户 2257462 的推流情况。

这样2257462推流情况和2105122 拉流情况一目了然对比了出来。

看推流的设备信息是声网机器人。

拉流端网络情况还可以，就是音频渲染卡顿时间比较久。音频播放频率和信号强度还算正常。

而推流的机器人，频繁上报网络断开事件。

所以问题到这，直接问题也就显现出来了。

小结结论：直接原因，推流端频繁掉线，所以声音不连续，导致拉流端卡顿。

喜欢深究问题的我，必然要问一句？为啥声网机器人会卡。之前工作经验告诉我可能是声网某个机房网络不好，或者单个机房的设备出现了问题？

带着这个问题，我去咨询了声网技术支持同事。问题真相才浮现出来。

这个连环故事是这样的。

1.2105122 用户在数据洞察 Plus上指标异常，音频卡顿率高是2257462的推流造成的。因为2257462用户频繁掉线。

2.而2257462用户却是一个机器人。这个机器人是我们在跨频道媒体转发场景使用的机器人。用来收对面主播的音频流的。

3.因为2257462机器人去收流的那个宿主主播他自己频繁掉线。所以那个主播和机器人频繁断开连接。

4.所以就导致这个整条链路卡顿的原因。A主播频繁掉线，小A是A主播的收流机器人，当然也和A主播频繁掉线断开连接，就导致小A机器人推出来的流也断断续续。最终当然导致拉流用户2105122音频卡顿啦。这就是整个链路卡顿原因的流程了。

故事讲到这，大家也就解除心中的疑惑了。也学习到了怎么使用【数据洞察Plus】希望大家也能把这好用的工具用起来，大家一起交流共勉。

如果在学习过程中遇到问题，可以随时给我留言。有空我会回来回复哒~