虎牙數萬主播同時在線直播的祕密，CDN推流日誌上行實時監控

時間 2019-12-04

原文原文鏈接

6 月 10 日，又拍雲 Open Talk | 2018 音視頻技術沙龍·深圳站順利落幕，來自虎牙的直播運維研發架構師張波在沙龍上作了《基於CDN推流日誌的主播上行實時監控及其自動化解密》的分享。虎牙直播是中國領先的互動直播平臺，做爲「遊戲直播第一股」，是音視頻技術的典型應用企業。
張波目前主要負責虎牙直播運維體系的建設，針對 Web 和後臺類程序的發佈、監控、運維自動化相關的運維繫統進行設計和開發。本次分享中，張波結合在一線工做中的實踐，介紹虎牙直播針對主播推流在 CDN 環境下的優化技巧，以及實踐過程當中碰到的各類坑。html

如下是分享內容：服務器

虎牙直播做爲遊戲直播平臺，擁有數百個產品線，同時在線主播數高達數萬，所以虎牙接入了多家 CDN 廠商。網絡

體量這麼大的主播上行量經過 CDN 端推流日誌如何作到自動監控，異常及時發現，業務如何經過系統準肯定位？架構

用戶側、網絡側、CDN 運營商側等引發的故障，如何作到故障分鐘定位？app

先與用戶發現定位系統問題瓶頸，如何用數據指引 CDN 提高服務質量呢？運維

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

首先是主播監控手段，最直接、最低延時的監控手段是觀察用戶彈幕喊卡。性能

當彈幕開始喊卡時，開發會上系統查看端上上報的監控數據來定位問題。可是僅僅依靠服務端數據，是很難肯定問題是發生在哪裏的，線路、客戶端、CDN、IDC 都有可能出現問題。測試

直播出現問題的緣由有不少，咱們要如何準肯定位業務問題呢？優化

通常狀況下，當虎牙主播直播出現問題後，開發會讓運維提供 CDN 服務器端數據，來定位問題，再由運維聯繫 CDN 運營商排查問題，最後由 CDN 廠商解決問題。

除此以外，虎牙還有其餘的監控方案：

第三方撥測監控;
端上報數據監控(主播端上報，用戶端上報)；
彈幕喊卡監控
服務端數據監控；
機房網絡監控。

CDN 側健康管理

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

上圖系統的核心功能主要有：

創建應用服務監控視圖；
關注應用性能；
多段、多層數據關聯分析；
瞭解用戶感知；
瞭解應用最終交付狀態；
瞭解應用對業務的影響；
端到端覆蓋應用路徑；
追蹤應用服務質量；
快速診斷和定位故障。

圖中也顯示了各個線路的質量狀況，虎牙每 20 秒檢測一個節點狀況，而 CDN 的線路圖，監控時效性是一分鐘延遲，所以全網 CDN 上行質量出現問題的話，會在一分鐘內發出告警。同時全網的出現卡頓的主播在卡頓監控中能夠試試看到，並實現定位上行卡頓緣由，迅速排出是不是廠商線路問題或運營商線路問題。

CDN 端到端的應用性能管理

上圖是監測系統的核心功能——端到端的應用性能管理，圖中描述了主播上行鏈路，上行方式分爲 CDN 上行和虎牙上行，CDN 上行是指經過 CDN 上行服務進行上行傳輸。

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

因此直播上行可能會出現的故障，要麼是主播端設備問題，要麼是主播端到上行節點網絡問題，或者是 CDN 上行服務器節點自身問題，再或者是上行視頻轉推給其餘 CDN 廠商轉推問題。

性能數據要覆蓋哪些項目

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

主播端主要根據這些參數進行監控，好比 Block 阻塞次數、CPU、解碼 CPU、模板 CPU、內存以及斷開緣由等監控指標。

IDC 層與 CDN 層監控指標相對較少，只有卡頓率和性能指數，此次分享也主要講解性能指數。

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

實時監控須要注意的技術點

在實時監控這方面，咱們使用的相關技術點，主要有：

流計算：sprak
實時日誌存儲：內部日誌索引服務
數據存儲：Hbase、Opentsdb

主播上行部分數據處理量並不大，即便是虎牙這個體量的直播平臺，原始日誌一秒一條日誌5秒合併輸出一條。

aac:0  bigint 接收或者發送aac的次數
abytes:4017#5733#7186#5642#4179  string  接收或者發送的音頻字節數
adrop:0#0#0#0#0  string 音頻發送丟幀數
afcnt:30#43#53#42#31 string 音頻幀數
afts:468664897#468665895#468667126#468668101#468668821 string 音頻時間戳
agap:0#0#0#0#0 string 音頻幀最大接收間隔(ms)
app:hunantv  string  rtmp協議中的app
appbuf:0#0#0#0#0  string 應用層發送隊列長蘇
avc:0  bigint 接收或者發送的avc的次數
block:0  bigint 卡頓次數
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發送大小
retrans:0#0#0#0#0 string 重傳包數
rtt:1#1#1#1#1 string  tcp層的rtt (ms)
rwd:0 string tcp的接收窗口大小.目前爲空
sndbuf:0 string tcp的發送大小
tcpbuf:715#2841#1808#19705#724 string tcp的buffer大小 字節數
vbytes:64523#51103#64525#103969#68513 string 接收發送的音頻字節數
vdrop:0#0#0#0#0  string 視頻丟幀數
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 上行日誌，能夠看到其中的描述項很是多，可以直接反應主播上行質量的指標並很少。

咱們要如何從日誌中挑選出須要的數據進行監控呢？

its 採集時間戳(毫秒)
uip 主播IP,點分十進制
inip 節點IP,點分十進制
inarea 節點省份
inisp 節點ISP信息
streamhost 流域名,如：tx.direct.huya.com
streamname 流名稱
vfps 視頻幀率 (5秒一條數據，1秒一個值，每一個值用#分隔）
vts 視頻時間戳(毫秒) (5秒一條數據，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}]

△ 虎牙統一上行標準日誌

上面表格是日誌監控解決方案，虎牙定義了用於監控的標準日誌。統一標準後的日誌對比以前的日誌減小不少內容。

重點提取了採集時間戳、主播 IP、節點 IP、節點省份、推流域名、視頻幀率、視頻時間戳、音頻時間戳、音頻幀率等監控項數據，有利於對數據進行分析。

如何設計統一上行質量度量方式

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

Apdex 會定義應用響應時間的最優門檻爲 T，另外根據應用響應時間結合 T 定義了三種不一樣的性能表現：

Satisfied（優質）：應用響應時間低於或等於 T（T 由性能評估人員根據預期性能要求肯定），好比 T 爲 1.5s，則一個耗時 1s 的響應結果則能夠認爲是 satisfied 的；
Tolerating（可容忍）：應用響應時間大於 T，但同時小於或等於 4T。假設應用設定的 T 值爲 1s，則 4 * 1 = 4 秒極爲應用響應時間的容忍上限；
Frustrated（劣質）：應用響應時間大於 4T。

這個方案描述了服務質量如何度量，它將服務質量分爲三部分：優質樣本

可容忍樣本、劣質樣本。

這樣操做就把複雜的操做變簡單，三級度量，每一級度量都會有對應的分值，優質樣本1分，可容忍樣本0.5分，劣質樣本0分，複雜問題經過計算公式簡單化。

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

咱們能夠這樣來看，在幀率沒有出現明顯抖動時，用戶感受不到卡頓，咱們就沒有必要把這個上行定義爲問題。