本文主要介紹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，具體詳見:【編風網】