摘要：張波目前主要負責虎牙直播運維體系的建設，針對和后臺類程序的發(fā)布監(jiān)控運維自動化相關的運維系統(tǒng)進行設計和開發(fā)。

6 月 10 日，又拍云 Open Talk | 2018 音視頻技術沙龍·深圳站 順利落幕，來自虎牙的直播運維研發(fā)架構師張波在沙龍上做了《基于CDN推流日志的主播上行實時監(jiān)控及其自動化解密》的分享?；⒀乐辈ナ侵袊I先的互動直播平臺，作為“游戲直播第一股”，是音視頻技術的典型應用企業(yè)。
張波目前主要負責虎牙直播運維體系的建設，針對 Web 和后臺類程序的發(fā)布、監(jiān)控、運維自動化相關的運維系統(tǒng)進行設計和開發(fā)。本次分享中，張波結合在一線工作中的實踐，介紹虎牙直播針對主播推流在 CDN 環(huán)境下的優(yōu)化技巧，以及實踐過程中碰到的各種坑。
以下是分享內(nèi)容：

虎牙直播作為游戲直播平臺，擁有數(shù)百個產(chǎn)品線，同時在線主播數(shù)高達數(shù)萬，因此虎牙接入了多家 CDN 廠商。

體量這么大的主播上行量通過 CDN 端推流日志如何做到自動監(jiān)控，異常及時發(fā)現(xiàn)，業(yè)務如何通過系統(tǒng)準確定位？

用戶側、網(wǎng)絡側、CDN 運營商側等引起的故障，如何做到故障分鐘定位？

先與用戶發(fā)現(xiàn)定位系統(tǒng)問題瓶頸，如何用數(shù)據(jù)指引 CDN 提升服務質量呢？

這次分享，我們就來聊聊如何解決這些問題。

首先是主播監(jiān)控手段，最直接、最低延時的監(jiān)控手段是觀察用戶彈幕喊卡。

當彈幕開始喊卡時，開發(fā)會上系統(tǒng)查看端上上報的監(jiān)控數(shù)據(jù)來定位問題。但是僅僅依靠服務端數(shù)據(jù)，是很難確定問題是發(fā)生在哪里的，線路、客戶端、CDN、IDC 都有可能出現(xiàn)問題。

直播出現(xiàn)問題的原因有很多，我們要如何準確定位業(yè)務問題呢？

一般情況下，當虎牙主播直播出現(xiàn)問題后，開發(fā)會讓運維提供 CDN 服務器端數(shù)據(jù)，來定位問題，再由運維聯(lián)系 CDN 運營商排查問題，最后由 CDN 廠商解決問題。

除此之外，虎牙還有其他的監(jiān)控方案：

第三方撥測監(jiān)控;

端上報數(shù)據(jù)監(jiān)控(主播端上報，用戶端上報)；

彈幕喊卡監(jiān)控

服務端數(shù)據(jù)監(jiān)控；

機房網(wǎng)絡監(jiān)控。

面向用戶體驗端到端的健康管理，范圍比較大。本次分享主要講一下 CDN 側的健康管理，比如判斷 CDN 是否存在問題？

上圖系統(tǒng)的核心功能主要有：

建立應用服務監(jiān)控視圖；

關注應用性能；

多段、多層數(shù)據(jù)關聯(lián)分析；

了解用戶感知；

了解應用最終交付狀態(tài)；

了解應用對業(yè)務的影響；

端到端覆蓋應用路徑；

追蹤應用服務質量；

快速診斷和定位故障。

圖中也顯示了各個線路的質量情況，虎牙每 20 秒檢測一個節(jié)點情況，而 CDN 的線路圖，監(jiān)控時效性是一分鐘延遲，因此全網(wǎng) CDN 上行質量出現(xiàn)問題的話，會在一分鐘內(nèi)發(fā)出告警。同時全網(wǎng)的出現(xiàn)卡頓的主播在卡頓監(jiān)控中可以試試看到，并實現(xiàn)定位上行卡頓原因，迅速排出是否是廠商線路問題或運營商線路問題。

上圖是監(jiān)測系統(tǒng)的核心功能——端到端的應用性能管理，圖中描述了主播上行鏈路，上行方式分為 CDN 上行和虎牙上行，CDN 上行是指通過 CDN 上行服務進行上行傳輸。

當 CDN 端接收到上行視頻后，會進行轉碼和轉推，轉推就是指將虎牙主播的上行流視頻轉推給其他廠商，讓用戶在各個廠商和線路上觀看到直播。

所以直播上行可能會出現(xiàn)的故障，要么是主播端設備問題，要么是主播端到上行節(jié)點網(wǎng)絡問題，或者是 CDN 上行服務器節(jié)點自身問題，再或者是上行視頻轉推給其他 CDN 廠商轉推問題。

上面這個表格是虎牙實時監(jiān)控平臺的部分核心功能以及性能指標的覆蓋項。

主播端主要根據(jù)這些參數(shù)進行監(jiān)控，比如 Block 阻塞次數(shù)、CPU、解碼 CPU、模板 CPU、內(nèi)存以及斷開原因等監(jiān)控指標。

IDC 層與 CDN 層監(jiān)控指標相對較少，只有卡頓率和性能指數(shù)，這次分享也主要講解性能指數(shù)。

在用戶端虎牙設置了感官卡比監(jiān)控指標，感官卡比就是用戶真實感受卡頓的比例，除了感官卡比之外，還有解碼方式、主動丟幀等監(jiān)控項。

在實時監(jiān)控這方面，我們使用的相關技術點，主要有：

流計算：sprak

實時日志存儲：內(nèi)部日志索引服務

數(shù)據(jù)存儲：Hbase、Opentsdb

主播上行部分數(shù)據(jù)處理量并不大，即使是虎牙這個體量的直播平臺，原始日志一秒一條日志5秒合并輸出一條。

aac:0  bigint 接收或者發(fā)送aac的次數(shù)
abytes:4017#5733#7186#5642#4179  string  接收或者發(fā)送的音頻字節(jié)數(shù)
adrop:0#0#0#0#0  string 音頻發(fā)送丟幀數(shù)
afcnt:30#43#53#42#31 string 音頻幀數(shù)
afts:468664897#468665895#468667126#468668101#468668821 string 音頻時間戳
agap:0#0#0#0#0 string 音頻幀最大接收間隔(ms)
app:hunantv  string  rtmp協(xié)議中的app
appbuf:0#0#0#0#0  string 應用層發(fā)送隊列長蘇
avc:0  bigint 接收或者發(fā)送的avc的次數(shù)
block:0  bigint 卡頓次數(shù)
bwin:0.0000  double 入帶寬
bwout:76382.0000  double 出帶寬
gop:180871  bigint 關鍵幀序號
mss:1460#1460#1460#1460#1460  string  mss大小
netqlen:96617#70188#57206#74576#106873  string tcp發(fā)送大小
retrans:0#0#0#0#0 string 重傳包數(shù)
rtt:1#1#1#1#1 string  tcp層的rtt (ms)
rwd:0 string tcp的接收窗口大小.目前為空
sndbuf:0 string tcp的發(fā)送大小
tcpbuf:715#2841#1808#19705#724 string tcp的buffer大小 字節(jié)數(shù)
vbytes:64523#51103#64525#103969#68513 string 接收發(fā)送的音頻字節(jié)數(shù)
vdrop:0#0#0#0#0  string 視頻丟幀數(shù)
vfcnt:17#25#31#25#17 string 視頻幀率
vfts:468664864#468665864#468667104#468668104#468668784 string 視頻時間戳
vgap:0#0#0#0#0 string 視頻幀之間最大間隔 (ms)
vhost:xx.mgtv.com string  域名
vname:xx.mgtv.com_HNGGMPP360 string 流名

上面這個表格是 CDN 上行日志，可以看到其中的描述項非常多，能夠直接反應主播上行質量的指標并不多。

我們要如何從日志中挑選出需要的數(shù)據(jù)進行監(jiān)控呢？

its 采集時間戳(毫秒)
uip 主播IP,點分十進制
inip 節(jié)點IP,點分十進制
inarea 節(jié)點省份
inisp 節(jié)點ISP信息
streamhost 流域名,如：tx.direct.huya.com
streamname 流名稱
vfps 視頻幀率 (5秒一條數(shù)據(jù)，1秒一個值，每個值用#分隔）
vts 視頻時間戳(毫秒) (5秒一條數(shù)據(jù)，1秒一個值，每個值用#分隔）
afps 音頻幀率
ats 音頻時間戳(毫秒)
[{"afps":30,"ats":9689432,"inarea":"河北","inip":"124.239.xxx.xx","inisp":"電信","its":1521530182,"streamhost":"ws.xxx.huya.com","streamname":"/huya/xxx-xx-xx-xxx-xx-A-xxx-1","uip":"123.182.xx.xxx","vfps":30,"vts":9689399}]

△ 虎牙統(tǒng)一上行標準日志

上面表格是日志監(jiān)控解決方案，虎牙定義了用于監(jiān)控的標準日志。統(tǒng)一標準后的日志對比之前的日志減少很多內(nèi)容。

重點提取了采集時間戳、主播 IP、節(jié)點 IP、節(jié)點省份、推流域名、視頻幀率、視頻時間戳、音頻時間戳、音頻幀率等監(jiān)控項數(shù)據(jù)，有利于對數(shù)據(jù)進行分析。

在度量上行質量方面，虎牙使用的是一個國際通用標準，Apdex 是用戶對應用性能滿意度的量化值。它提供了一個統(tǒng)一的測量和報告用戶體驗的方法，把最終用戶的體驗和應用性能作為一個完整的指標進行統(tǒng)一度量。

Apdex 會定義應用響應時間的最優(yōu)門檻為 T，另外根據(jù)應用響應時間結合 T 定義了三種不同的性能表現(xiàn)：

Satisfied（優(yōu)質）：應用響應時間低于或等于 T（T 由性能評估人員根據(jù)預期性能要求確定），比如 T 為 1.5s，則一個耗時 1s 的響應結果則可以認為是 satisfied 的；

Tolerating（可容忍）：應用響應時間大于 T，但同時小于或等于 4T。假設應用設定的 T 值為 1s，則 4 * 1 = 4 秒極為應用響應時間的容忍上限；

Frustrated（劣質）：應用響應時間大于 4T。

這個方案描述了服務質量如何度量，它將服務質量分為三部分：優(yōu)質樣本

可容忍樣本、劣質樣本。

這樣操作就把復雜的操作變簡單，三級度量，每一級度量都會有對應的分值，優(yōu)質樣本1分，可容忍樣本0.5分，劣質樣本0分，復雜問題通過計算公式簡單化。

再者，上行質量要怎么去度量呢？

我們可以這樣來看，在幀率沒有出現(xiàn)明顯抖動時，用戶感覺不到卡頓，我們就沒有必要把這個上行定義為問題。

樣本：當前平均幀率與前兩秒抖動最大差值
優(yōu)質樣品: 0% <= 評分 < 5%
可容忍樣品: 5% <= 評分 < 10%
劣質樣品: 10% <= 評分

虎牙通過測量當前平均幀率與前兩秒抖動最大差值，來度量優(yōu)質樣本。

優(yōu)質樣本要求評分在 0% 到 5%，可容忍樣品在 5% 到 10%，劣質樣本小于等于10%。

一般來說，如果主播視頻的平均上行幀率是 30 幀，5%是指抖動 1 秒產(chǎn)生的抖動幀是 1.5 幀。

1.5 抖動幀，大部分人感覺不到畫面抖動，但是達到 3 幀時，用戶就能感受到畫面的抖動。

虎牙的計算方式是實時和離線結合的，實時計算由于數(shù)據(jù)延遲，或者實時計算問題，導致數(shù)據(jù)不太精準。

如果要實時計算的數(shù)據(jù)作為調度或者廠商質量評判標準的話，就需要輔以離線計算，讓數(shù)據(jù)更準確，才能指導廠商優(yōu)化節(jié)點以及調度服務優(yōu)化線路。

主播上行實時監(jiān)控的應用場景有四個方面：

1. CDN 入圍測試：制定入圍標準，上行接入質量達到，縮短測試周期

2. CDN 運行監(jiān)控：實時獲取CDN端運行數(shù)據(jù)，對可能的主播運行風險進行及時預警，實現(xiàn)主播級的故障自愈和問題定位

3. 節(jié)點質量管理：實時評價CDN上行節(jié)點健康度，主動發(fā)現(xiàn)影響客戶體驗因素，屏蔽質量較差的節(jié)點和線路

4.主播上行，運營分析：利用全方位的主播上行性能數(shù)據(jù)，出具主播質量和線路質量性能報告，從業(yè)務角度為主播上行質量運營提供分析數(shù)據(jù)。

查看講師分享 PPT 和分享視頻，請進入下方傳送門：

基于CDN推流日志的主播上行實時監(jiān)控及其自動化解密