6月10日，又拍云 Open Talk | 2018 音视频技术沙龙·深圳站 顺利落幕，来自虎牙的直播运维研发架构师张波在沙龙上做了《基于CDN推流日志的主播上行实时监控及其自动化解密》的分享。虎牙直播是中国领先的互动直播平台，作为“游戏直播第一股”，是音视频技术的典型应用企业。
张波目前主要负责虎牙直播运维体系的建设，针对 Web 和后台类程序的发布、监控、运维自动化相关的运维系统进行设计和开发。本次分享中，张波结合在一线工作中的实践，介绍虎牙直播针对主播推流在 CDN 环境下的优化技巧，以及实践过程中碰到的各种坑。
虎牙直播作为游戏直播平台，拥有数百个产品线，同时在线主播数高达数万，因此虎牙接入了多家 CDN 厂商。
体量这么大的主播上行量通过 CDN 端推流日志如何做到自动监控，异常及时发现，业务如何通过系统准确定位？
用户侧、网络侧、CDN 运营商侧等引起的故障，如何做到故障分钟定位？
先与用户发现定位系统问题瓶颈，如何用数据指引 CDN 提升服务质量呢？
这次分享，我们就来聊聊如何解决这些问题。
首先是主播监控手段，直接、低延时的监控手段是观察用户弹幕喊卡。
当弹幕开始喊卡时，开发会上系统查看端上上报的监控数据来定位问题。但是仅仅依靠服务端数据，是很难确定问题是发生在哪里的，线路、客户端、CDN、IDC 都有可能出现问题。
直播出现问题的原因有很多，我们要如何准确定位业务问题呢？
一般情况下，当虎牙主播直播出现问题后，开发会让运维提供 CDN 服务器端数据，来定位问题，再由运维联系 CDN 运营商排查问题，由 CDN 厂商解决问题。
除此之外，虎牙还有其他的监控方案：
1. 第三方拨测监控;
2. 端上报数据监控(主播端上报，用户端上报)；
3. 弹幕喊卡监控
4. 服务端数据监控；
5. 机房网络监控。
CDN 侧健康管理
面向用户体验端到端的健康管理，范围比较大。本次分享主要讲一下 CDN 侧的健康管理，比如判断 CDN 是否存在问题？
上图系统的核心功能主要有：
1. 建立应用服务监控视图；
2. 关注应用性能；
3. 多段、多层数据关联分析；
4. 了解用户感知；
5. 了解应用交付状态；
6. 了解应用对业务的影响；
7. 端到端覆盖应用路径；
8. 追踪应用服务质量；
9. 快速诊断和定位故障。
图中也显示了各个线路的质量情况，虎牙每 20 秒检测一个节点情况，而 CDN 的线路图，监控时效性是一分钟延迟，因此全网 CDN 上行质量出现问题的话，会在一分钟内发出告警。同时全网的出现卡顿的主播在卡顿监控中可以试试看到，并实现定位上行卡顿原因，迅速排出是否是厂商线路问题或运营商线路问题。
CDN 端到端的应用性能管理
上图是监测系统的核心功能——端到端的应用性能管理，图中描述了主播上行链路，上行方式分为 CDN 上行和虎牙上行，CDN 上行是指通过 CDN 上行服务进行上行传输。
当 CDN 端接收到上行视频后，会进行转码和转推，转推就是指将虎牙主播的上行流视频转推给其他厂商，让用户在各个厂商和线路上观看到直播。
所以直播上行可能会出现的故障，要么是主播端设备问题，要么是主播端到上行节点网络问题，或者是 CDN 上行服务器节点自身问题，再或者是上行视频转推给其他 CDN 厂商转推问题。
性能数据要覆盖哪些项目
上表是虎牙实时监控平台的部分核心功能以及性能指标的覆盖项。
主播端主要根据这些参数进行监控，比如 Block 阻塞次数、CPU、解码 CPU、模板 CPU、内存以及断开原因等监控指标。
IDC 层与 CDN 层监控指标相对较少，只有卡顿率和性能指数，这次分享也主要讲解性能指数。
在用户端虎牙设置了感官卡比监控指标，感官卡比就是用户真实感受卡顿的比例，除了感官卡比之外，还有解码方式、主动丢帧等监控项。
实时监控需要注意的技术点
在实时监控这方面，我们使用的相关技术点，主要有：
1. 流计算：sprak
2. 实时日志存储：内部日志索引服务
3. 数据存储：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 上行日记
上面这个表格是 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 定义了三种不同的性能表现：
1. Satisfied（优质）：应用响应时间低于或等于 T（T 由性能评估人员根据预期性能要求确定），比如 T 为 1.5s，则一个耗时 1s 的响应结果则可以认为是 satisfied 的；
2. Tolerating（可容忍）：应用响应时间大于 T，但同时小于或等于 4T。假设应用设定的 T 值为 1s，则 4 * 1 = 4 秒极为应用响应时间的容忍上限；
3. Frustrated（劣质）：应用响应时间大于 4T。
这个方案描述了服务质量如何度量，它将服务质量分为三部分：优质样本、可容忍样本、劣质样本。
这样操作就把复杂的操作变简单，三级度量，每一级度量都会有对应的分值，优质样本 1 分，可容忍样本 0.5 分，劣质样本 0 分，复杂问题通过计算公式简单化。
再者，上行质量要怎么去度量呢？
我们可以这样来看，在帧率没有出现明显抖动时，用户感觉不到卡顿，我们就没有必要把这个上行定义为问题。
样本：当前平均帧率与前两秒抖动至大差值
优质样品: 0% <= 评分 < 5%
可容忍样品: 5% <= 评分 < 10%
劣质样品: 10% <= 评分
虎牙通过测量当前平均帧率与前两秒抖动至大差值，来度量优质样本。
优质样本要求评分在 0% 到 5%，可容忍样品在 5% 到 10%，劣质样本小于等于10%。
一般来说，如果主播视频的平均上行帧率是 30 帧，5%是指抖动 1 秒产生的抖动帧是 1.5 帧。
1.5 抖动帧，大部分人感觉不到画面抖动，但是达到 3 帧时，用户就能感受到画面的抖动。
通过实时/离线计算结合，提升数据准确性
虎牙的计算方式是实时和离线结合的，实时计算由于数据延迟，或者实时计算问题，导致数据不太精准。
如果要实时计算的数据作为调度或者厂商质量评判标准的话，就需要辅以离线计算，让数据更准确，才能指导厂商优化节点以及调度服务优化线路。
主播上行质量实时监控系统应用的典型场景
主播上行实时监控的应用场景有四个方面：
1. CDN 入围测试：制定入围标准，上行接入质量达到，缩短测试周期
2. CDN 运行监控：实时获取CDN端运行数据，对可能的主播运行风险进行及时预警，实现主播级的故障自愈和问题定位
3. 节点质量管理：实时评价CDN上行节点健康度，主动发现影响客户体验因素，屏蔽质量较差的节点和线路
4. 主播上行，运营分析：利用全方位的主播上行性能数据，出具主播质量和线路质量性能报告，从业务角度为主播上行质量运营提供分析数据。
