随着WebRTC的兴起和标准化，基于浏览器的视频会议解决方案已经变得非常流行。但是，在每天数百万用户的规模上支持这种复杂的系统是一种不同的挑战。
为什么WebRTC系统的故障排除如此困难？
WebRTC是很棘手的。它试图使非常复杂的过程变得简单。但是，随着这种简单性的出现，你需要掌握非常广泛的知识，以便有效地使用这种很酷的技术创建系统。你可以把这些知识分成3个主要的主题：媒体处理、网络和信令基础设施。此外，还有更多的竞赛条件是你无法想象或再现的。
在这篇文章中，我将给你指示你可能需要的工具，以支持你的WebRTC视频会议应用。这些话来自于我将我们的会议解决方案扩展和支持到数百万用户的经验。
我们是如何开始的？
我们的故事始于5年前，在特拉维夫市中心的一个小办公室里，一家小型创业公司（Newrow，两年后被Kaltura收购）开始为其虚拟教室解决方案争取真正的客户。
随着真正的客户开始出现真正的错误。起初，这些错误是相当容易重现的。慢慢地，它们变得更加神秘和难以理解。我们明白，除了我们的产品经理给我们转发愤怒的电子邮件之外，我们还需要其他东西。
日志、日志、还有更多的日志
开始任何调查首先需要的是证据。你拥有的证据越多，你将得到更好的结论。
对于任何开发人员来说，最好的证据来源是日志，所以我们决定必须有一个系统，可以按需收集和显示日志。我在这里的重点将是客户端的日志，因为WebRTC的大部分乐趣都是从浏览器开始的。
有很多产品可以帮助你实现收集客户端日志的任务，但随着你的应用程序的增长，它们变得非常昂贵。不幸的是，对于WebRTC来说，有大量的日志需要收集。
我们决定从一个简单的解决方案开始，它可以将压缩的zip日志文件上传到云存储（如AWS S3），并将它们与客户反馈单关联起来。
当客户提交反馈时，客户会向我们发送与该会话相关的相关数据。此外，我们计算所有参与者在特定时刻的 WebRTC 统计数据。我们通过惨痛的教训了解到，报告用户不一定是有问题的用户。
以下是我们在事件发生时从每个对等连接收到的一些数据：
- 信令状态——了解您是否设置了 SDP 非常有用
- ICE 连接状态 + 连接状态——通常都显示相同的值，但连接状态也反映了 DTLS 状态。
- 对等连接的创建和销毁时间——由此，您还可以计算对等连接的持续时间。
- getUserMedia 约束和错误——这些错误通常有助于支持工程师在您不参与的情况下直接与客户合作。
- 所有检测到的 ICE 候选类型列表
- 这是发布连接还是查看连接？
- WebRTC 统计信息，例如数据包丢失、RTT、抖动等
在原始数据之上，我们添加了一些简单的 UI 来显示日志的内容。非常类似于终端。没什么特别的，但很有效。
注意事项：确保您偶尔清理日志。否则，您将存储陈旧且无用的数据并为此付出高昂代价。
更上一层楼
当我们的系统达到数万个并发用户时，我们无法访问为我们团队打开的所有支持工单。我们决定将错误检测向前推进一步，并开始构建一个工具来主动收集 RTC 统计数据和其他信息。
浏览器免费为我们提供了如此多的统计数据，那么为什么不用它来查找错误呢？
我们决定收集的最强数据点之一是关闭对等连接的原因。正常吗？它被打断了吗？连接甚至建立了吗？
此外，对于每个对等连接，您可以获得统计信息，例如音频/视频总字节数、对等连接状态、ICE 连接状态、查看者或发布者、建立连接所花费的时间以及该对等连接所花费的时间交换 SDP 提议/答案。
这有助于我们对数据进行分类并找到真正简单但有趣的趋势。
我们如何收集统计数据？
当对等连接达到最终状态时，我们计算相关数据并将其发送到 NGINX 服务器集群。每个 NGINX 服务器记录请求并解析它。接下来，我们使用td-agent将数据提取、转换并加载到 ElasticSearch 中。最后，我们探索数据并构建可视化和仪表板。
这种设计有几个好处：
- 扩展起来非常容易，因为我们只是在扩展 NGINX 日志。K8s 集群中的几个小 pod 可以完成最高负载的工作。
- 它比完全托管的解决方案便宜。您只需为部分存储空间和运行中的 ElasticSearch 付费。
- 初始设置后几乎不需要维护。只需偶尔清除旧数据即可。
得到教训
- 使用 window.onunload 事件收集有关用户关闭浏览器选项卡/窗口时处于活动状态的 peerConnections 的数据。这保证您不会丢失大部分数据。其中大部分通常是在整个通话过程中成功连接并运行良好的对等连接。
- 使计算有效负载的过程同步，因为当浏览器关闭选项卡时，您将无法完成异步操作。这是非常棘手的，因为 getStats 方法是异步的。但是通过正确的设计和实现，你可以获得足够好的结果。您不必精确到字节！
- 使用 navigator.sendbeacon 方法发送信标。这保证即使浏览器选项卡关闭也能发送数据。此 API 不等待响应，因此非常适合第 1点和第 2 点。
我们如何结合这两种工具？
在这一点上，我们的系统有 2 个非常强大的诊断和研究工具。我们现在可以在我们的系统中发现有趣的趋势和错误。我们可以评估新发布功能的质量。当然，我们可以调查数据并决定我们未来任务和开发工作的下一步行动方案。
以下是我们如何使用这些机制的 2 个示例。
- 在 getUserMedia 失败后挂起对等连接
我们看到了一种趋势，即我们发布的对等连接卡在 connectionState“new”中。这很奇怪，因为这意味着我们还没有达到设置本地 SDP 的地步。在对这些信标进行调查后，我们发现很多对等连接都没有成功获取用户媒体。我们在应用程序的一个流程中有一个错误，尽管 getUserMedia 失败了，但它仍然创建了对等连接。 - 监控
每次发布后，我们都会监控我们的统计数据，看看是否有意想不到的趋势。这方面的一个例子是当我们看到异常断开时出现周期性峰值。我们发现我们在我们的自动缩放机制中引入了一个错误，该错误过早地缩小了 SFU，而它们仍然有一些用途。如果没有我们的 RTC 统计基础设施，发现和修复此类错误将非常具有挑战性。
最后的话和想法
这些工具现在是我和我的团队日常工作流程的一部分。每天早上，我都会查看我关注的最新趋势。这就是我们“生活在系统中”的方式。从长远来看，就解决的错误和客户满意度而言，这种基础架构为我们节省了大量金钱和时间。
最后，收集如此多的数据为解决视频会议领域的其他问题打开了一些有趣的大门，例如质量评估。我相信在不久的将来，我们也会朝着这个方向努力。
作者：Denis Sicun
原文：https://medium.com/kaltura-tech/tools-we-developed-to-troubleshoot-webrtc-at-high-scale-ffaced489b7d
本文为原创稿件，版权归作者所有，如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/27591.html
