線上服務的有效監(jiān)控和數(shù)據(jù)收集，一直是后端服務離不開的話題。直播作為一種經(jīng)典的分布式系統(tǒng)，監(jiān)控以及數(shù)據(jù)收集更是必不可少的工作。如何對海量的服務集群有效的監(jiān)控和保活，又如何抓取集群中的碎片數(shù)據(jù)中來優(yōu)化服務？網(wǎng)易云信音視頻研發(fā)工程師將和大家共同探討。

?

推薦閱讀

視頻私有云實戰(zhàn)：基于Docker構建點播私有云平臺

高清音質(zhì)背后：網(wǎng)易云信音樂教學方案技術解密

?

機器站在巨人的肩膀上用著輪子

作為分布式集群，物理層上的最小單位自然是機器。對于一臺機器而言，常規(guī)性能指標自然就是CPU、內(nèi)存、網(wǎng)卡的使用情況。這些性能有很多方式去獲取，而視頻云采用的是網(wǎng)易的哨兵系統(tǒng)。哨兵系統(tǒng)是網(wǎng)易的監(jiān)控系統(tǒng)，提供了非常詳細和即時的性能指標。

借由哨兵這個強大的輪子，我們能非常方便的在機器級別上，做出有效的監(jiān)控。例如當網(wǎng)卡流量或者cpu異常的時候，可以快速的報警采取處理。當然，不光光可以監(jiān)控機器是否能正常運行，也可以監(jiān)控是否被惡意攻擊，這個暫且不談。

?

性能指標與業(yè)務融合

當然，只有機器級的數(shù)據(jù)，是遠遠不夠的。俗話說，不與業(yè)務貼合的數(shù)據(jù)，不是好數(shù)據(jù)。作為直播CDN服務，最常規(guī)的參數(shù)，自然是音視頻碼率和延遲。

細心的看官們可能發(fā)現(xiàn)了幾個比較特殊的統(tǒng)計。

為什么統(tǒng)計了總碼率也統(tǒng)計了音視頻單獨的碼率？

這是因為在真實的場景中，總碼率并不一定能還原出我們需要的場景，有很多情況會需要單獨的分析音視頻碼率，例如用戶主動關閉了視頻輸出或者機器采樣性能不足導致的視頻卡頓，這個時候只需要配合幀率的統(tǒng)計，就可以快速還原場景。當然，視頻碼率本身也不是一個固定的數(shù)值。視頻云也針對弱網(wǎng)提供QoS（即可變碼率）的功能。

推送延遲push_delay是什么？

推送延遲，是一個衡量C/S之間網(wǎng)絡情況的參數(shù)。當這個參數(shù)發(fā)生波動的時候，則說明C端的包到達S的時間比預計要長。能夠反映出網(wǎng)絡的抖動情況。如果計算這個數(shù)值呢？簡單來說，是使用了RTMP包頭部的時間戳。如果非要用一個公式解釋一下，我覺得應該是：

Delay=abs( (當前RTMP包的到達時間-上個RTMP包的到達時間) – (當前RTMP包的時間戳–上個RTMP包的時間戳) )

計算每個包到達服務器所消耗時間的差異值，用于代表網(wǎng)絡的抖動。當然，還需要做其他很多事情，例如加權和jitter算法來減少誤差和避免。

為什么還有send_kbps？

其實這也挺好理解，因為CDN本身是分布式系統(tǒng)，在節(jié)點和節(jié)點間需要做路徑選擇，然后從節(jié)點到節(jié)點傳輸，從而實現(xiàn)加速。Send_kbps其實就是前一個節(jié)點向后一個節(jié)點的發(fā)送碼率。那么這就涉及到了一個問題，如果去trace某一條流的數(shù)據(jù)呢？對于每一條流，我們會給予一個唯一的標記，在節(jié)點間傳遞的時候，我們會給流添加一個自增的標記Hops。

通過這個標記，可以精準的找到這條流在節(jié)點件的走向，從而把各個節(jié)點的數(shù)據(jù)聚合在一起

其他，我們還會抓取一些類似源IP，用戶設備等客戶端的信息。這些信息能幫忙我們走進大數(shù)據(jù)時代。

?

整體數(shù)據(jù)服務的架構

分布式系統(tǒng)中，每一個節(jié)點都會產(chǎn)生大量的統(tǒng)計和性能數(shù)據(jù)。所以在視頻云，有一個完整的統(tǒng)計架構來作出支持。從最前端的數(shù)據(jù)采集、傳輸，到匯總，然后到計算集群，最后輸出。每一個服務都各司其職。讓我們來看看整體架構。

對于每一個區(qū)域，會有一個數(shù)據(jù)匯聚的服務器，負責從流媒體服務器收集數(shù)據(jù)。最初的元數(shù)據(jù)，經(jīng)過數(shù)據(jù)匯聚服務器匯總、過濾和壓縮以后。統(tǒng)一上報到中心集群中的統(tǒng)計服務器。統(tǒng)計服務器會將所有的統(tǒng)計數(shù)據(jù)，逐一落庫，儲存在數(shù)據(jù)倉庫中。其余的數(shù)據(jù)計算集群，會從數(shù)據(jù)倉庫中定時進行讀取計算。具體的計算間隔，會根據(jù)業(yè)務類型不同而不同。例如運維平臺會主要讀取一些機器級別的數(shù)據(jù)，進行分析和報警。大數(shù)據(jù)計算集群則會對數(shù)據(jù)進行計算，得出優(yōu)化方向，此處我們稍后再聊。業(yè)務數(shù)據(jù)展示平臺則是會實時的輸出數(shù)據(jù)（例如碼率和延遲），用于提供給用戶和技術支持查詢。當然，還有其他各種各樣的數(shù)據(jù)處理服務，這里就不再一一介紹。

?

數(shù)據(jù)能做的一些事情

最后，我們聊一聊數(shù)據(jù)。在這個大數(shù)據(jù)時代，有了數(shù)據(jù)卻不做事情，等同于浪費。那么，有了這些數(shù)據(jù)以后，我們做了什么事情呢？當然，最顯而易見的，就是調(diào)整調(diào)度策略，增設布點。例如，上圖的大數(shù)據(jù)的運算結(jié)果，南京電信的網(wǎng)絡權重比較差，這就說明南京電信地區(qū)需要進行排查。而南京移動的用戶量較大，也說明南京地區(qū)應該增設服務點。

此外，數(shù)據(jù)和性能指標的上報，也會被用于均衡負載調(diào)度。例如某一個節(jié)點壓力較大的時候，或者性能不穩(wěn)定的時候，這個節(jié)點的調(diào)度優(yōu)先級就會被降低（即不太會被優(yōu)先分配給用戶）。

以上就是我對于直播CDN服務監(jiān)控的一些看法，但是直播CDN服務監(jiān)控和數(shù)據(jù)收集是一個值得無止境討論和優(yōu)化的事情，歡迎大家留言與我探討。

想要獲取更多產(chǎn)品干貨、技術干貨，歡迎關注網(wǎng)易云信博客。

?

云信介紹參考：

網(wǎng)易云信（NeteaseYunXin）是集網(wǎng)易18年IM以及音視頻技術打造的PaaS服務產(chǎn)品，來自網(wǎng)易核心技術架構的通信與視頻云服務，穩(wěn)定易用且功能全面，致力于提供全球領先的技術能力和場景化解決方案。開發(fā)者通過集成客戶端SDK和云端OPEN API，即可快速實現(xiàn)包含IM、音視頻通話、直播、點播、互動白板、短信等功能。

總結(jié)

以上是生活随笔為你收集整理的直播技术：从性能参数到业务大数据，浅谈直播CDN服务监控的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。