線上服務的有效監控和數據收集，一直是后端服務離不開的話題。直播cdn作為一種經典的分布式系統，監控以及數據收集更是必不可少的工作。如何對海量的服務集群有效的監控和保活，又如何抓取集群中的碎片數據中來優化服務。不得不說是一個值得無止境討論和優化的事情。

?

●●●

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

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

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

?

●●●

性能指標與業務融合

當然，只有機器級的數據，是遠遠不夠的。俗話說，不與業務貼合的數據，不是好數據。作為直播cdn服務，最常規的參數，自然是音視頻碼率和延遲。

細心的看官們可能發現了幾個比較特殊的統計。

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

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

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

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

為什么還有send_kbps？其實這也挺好理解，因為CDN本身是分布式系統，在節點和節點間需要做路徑選擇，然后從節點到節點傳輸，從而實現加速。Send_kbps其實就是前一個節點向后一個節點的發送碼率。那么這就涉及到了一個問題，如果去trace某一條流的數據呢？對于每一條流，我們會給予一個唯一的標記，在節點間傳遞的時候，我們會給流添加一個自增的標記Hops。通過這個標記，可以精準的找到這條流在節點件的走向，從而把各個節點的數據聚合在一起

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

?

●●●

整體數據服務的架構

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

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

?

●●●

數據能做的一些事情

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

此外，數據和性能指標的上報，也會被用于均衡負載調度。例如某一個節點壓力較大的時候，或者性能不穩定的時候，這個節點的調度優先級就會被降低（即不太會被優先分配給用戶）。

——【特別推薦】——

不就是發個短信嗎？這你都會？

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。