從性能參數到業務大數據，淺談直播 CDN 服務監控

線上服務的有效監控和數據收集，一直是後端服務離不開的話題。直播 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，用戶設備等客戶端的信息。這些信息能幫忙咱們走進大數據時代（笑。

總體數據服務的架構

分佈式系統中，每個節點都會產生大量的統計和性能數據。因此在視頻雲，有一個完整的統計架構來做出支持。從最前端的數據採集、傳輸，到彙總，而後到計算集羣，最後輸出。每個服務都各司其職。讓咱們來看看總體架構。

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

數據能作的一些事情

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

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

---

還有更多幹貨，歡迎關注網易 MC 官方微信公衆號：