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

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

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

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

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

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

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

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

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

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

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

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

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

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

彈幕喊卡監(jiān)控

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

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

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

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

建立應(yīng)用服務(wù)監(jiān)控視圖；

關(guān)注應(yīng)用性能；

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

了解用戶感知；

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

了解應(yīng)用對業(yè)務(wù)的影響；

端到端覆蓋應(yīng)用路徑；

追蹤應(yīng)用服務(wù)質(zhì)量；

快速診斷和定位故障。

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

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

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

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

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

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

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

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

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

流計算：sprak

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

數(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 應(yīng)用層發(fā)送隊列長蘇
avc:0  bigint 接收或者發(fā)送的avc的次數(shù)
block:0  bigint 卡頓次數(shù)
bwin:0.0000  double 入帶寬
bwout:76382.0000  double 出帶寬
gop:180871  bigint 關(guān)鍵幀序號
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 上行日志，可以看到其中的描述項非常多，能夠直接反應(yīng)主播上行質(zhì)量的指標(biāo)并不多。

我們要如何從日志中挑選出需要的數(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)一上行標(biāo)準(zhǔn)日志

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

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

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

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

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

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

Frustrated（劣質(zhì)）：應(yīng)用響應(yīng)時間大于 4T。

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

可容忍樣本、劣質(zhì)樣本。

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

再者，上行質(zhì)量要怎么去度量呢？

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

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

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

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

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

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

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

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

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

1. CDN 入圍測試：制定入圍標(biāo)準(zhǔn)，上行接入質(zhì)量達到，縮短測試周期

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

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

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

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

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