摘要：線上服務的有效監(jiān)控和數(shù)據(jù)收集，一直是后端服務離不開的話題。性能指標與業(yè)務融合當然，只有機器級的數(shù)據(jù)，是遠遠不夠的。在這個大數(shù)據(jù)時代，有了數(shù)據(jù)卻不做事情，等同于浪費。而南京移動的用戶量較大，也說明南京地區(qū)應該增設服務點。

線上服務的有效監(jiān)控和數(shù)據(jù)收集，一直是后端服務離不開的話題。直播 CDN 作為一種經(jīng)典的分布式系統(tǒng)，監(jiān)控以及數(shù)據(jù)收集更是必不可少的工作。如何對海量的服務集群有效的監(jiān)控和?；?，又如何抓取集群中的碎片數(shù)據(jù)中來優(yōu)化服務。不得不說是一個值得無止境討論和優(yōu)化的事情。

作為分布式集群，物理層上的最小單位自然是機器。對于一臺機器而言，常規(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)控是否被惡意攻擊，這個暫且不談。

當然，只有機器級的數(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)絡的抖動。當然，還需要做其他很多事情，例如加權(quán)和 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ù)時代（笑。

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

對于每一個區(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ù)支持查詢。當然，還有其他各種各樣的數(shù)據(jù)處理服務，這里就不再一一介紹。

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

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

還有更多干貨，歡迎關注網(wǎng)易 MC 官方微信公眾號：