本文主要介绍WebRTC端到端监控（我们翻译和整理的，译者：weizhenwei，校验：blacker），最早发表在【编风网】
支持原创，转载必须注明出处，欢迎关注我的微信公众号blacker（微信ID：blackerteam 或 webrtcorgcn）。
callstats是一家做实时通讯性能测量的公司，他们博客里面提到了实时通讯过程中性能的重要性，下面是博客内容；
性能监控是系统和服务开发的一个重要方面，它可以帮助我们检测和诊断性能问题，并有助于维护系统的高可用性。现如今工程团队都基于数据做决策，因此这些性能测量在实施和部署问题修复方面发挥重要作用。
通常来说，服务监控的度量分为两类：
·规 模：系统负载，错误率，用户搅动，等等；
·持续时间：创建时间，事务响应时间，等等。
在度量方面,WebRTC并没有什么不同之处。一个规模度量的例子如同时在线或者建立失败的会议数目，一个持续时间度量的例子如建立一个连接的时间。
实时测量
在callstats.io，实时性是所有系统的重要衡量指标。当第一个参与者加入会议时，我们会立即对会议进行分类。如果一个会议创建失败，服务器能够立即发现失败及其失败原因和会议从启动到失败所消耗的时间。我们非常看中这种实时处理能力，它能够在事情发生时尽快发出警告，并立即呈现给用户。我们称之为“持续分析”。
正确的端到端监控
Callstats.io通过getStats() API或者基础度量监控WebRTC连接的重要方面，即来自实际用户的度量值（只有用户才能代表他们自己）。该方法用来测量：
·每对WebRTC设备的端到端网络性能。
·WebRTC设备的媒体性能。这包括与音频重放和视频渲染相关的大量度量。
这些度量针对每个连接、参会者和会议独立地进行汇总。
失败
基于时间的用户行为（如用户每天何时使用服务，或者在一周之中的某天使用服务），度量值每天都会发生波动变化。然而，过去几天或几周使用率的显著下降往往预示着服务出了问题。比如，会话建立失败的增加预示着基础设施、终端或者网络的故障。下图显示在一个会议期间可能发生错误的时刻。
会议建立期间错误的分类
WebRTC服务组件故障原因：
1.终端有可能改变行为。浏览器每六周更新一次，开发版和公测版可以更早于发布版得到。因此，开发团队对新特性和更新可能导致的问题有直觉。此外，Chrome和Firefox团队提前宣布PSA，并及时回答支持咨询。
2.基础设施可能过载。即服务器承受比预期更多的流量而导致性能问题。这也可能发生在底层基础设施消失，或者首次部署新特性导致影响到部分客户。
3.网络可能由于网络流量监管或者网络行为不确定发生拥塞。这可能影响地理上某些区域，或者某个特殊的网络服务提供商业/企业网络。典型地，这些情况下用户位于受限制防火墙背后，或者有网络设备发生故障。
服务中断
服务中断可能发生在一个或多个WebRTC服务基础组件停止工作时：
·信令服务器宕机：导致会话不能建立。在这种情况下，正在进行的会议数和会议总数将会降低。
·TURN服务器宕机：导致部分会话不能建立。在这种情况下，部分或者全部会议失败数目将会增加，这种失败归类为ICE连接失败。
·会议桥宕机：部分会话不能建立。一个或多个会议桥将会发送宕机报告。
向用户指出这些服务中断同样很重要。例如，告诉用户连向信令服务器或者会议桥的连接中断，或者会话正在试图重建，或者会话失败需要等待或立即重试。许多服务已经提供一些基本诊断，比如：音频仪，网络码率，静音指示，等等。
类似地，我们的API会显示网络连接状态和其它关键度量。这些度量可以以一种合适的界面呈现给终端用户，以帮助他们了解应用的当前状态，并缓解因为诊断到服务中断带来的挫败感。
收集终端用户反馈
收集终端用户反馈同样很重要，这有助于我们找到用户体验和客观质量(或者媒体和网络度量)之间的对应关系。纵观callstats.io的客户，我们发现10%~40%的会议有一个或多个用户反馈评论。反馈数量很大程度上取决于在合适的场景下提问合适的问题。
持续测试
在整个业界，自动化测试和持续集成是通行准则，这同样适用于WebRTC。浏览器厂商已经做了大量努力以实现测试过程自动化。此外，在Github上也有一些使用Selenium测试WebRTC的资源。
总结
在我们看来，对WebRTC进行端到端监控的最好方法就是用API把监控方案集成到WebRTC应用的核心单元。用这种方法，监控方案能够实时追踪规模度量和持续时间度量，向开发者提供WebRTC服务状态的实时信息。基于API的方案也提供很多回调的可能性，例如，自动调整WebRTC应用的性能以提供给终端用户尽可能好的媒体质量。
译者：weizhenwei，具体详见:【编风网】
