60毫秒,从海量直播日志中实时定位故障!

来源:互联网 发布:黑马程序员怎样 编辑:程序博客网 时间:2024/05/02 02:36

互动直播正在进入大数据时代


时间退回到2012年,互联网上最火的词那一定是“大数据”。经过这几年的发展,多样的、海量的数据爆发式增长,不同的数据分析处理模型和系统日益成熟,以及快速发展的分布式计算使得海量数据处理没有停留在概念阶段。大数据服务本身,以及基于大数据的“人工智能”和“深度学习”已经成熟的应用于诸多场景,基于大数据的商业决策、针对性市场营销、市场预测与生产优化、风险控制等等方面发挥着前所未有的能量,数据使用者们也因此而实现商业价值最大化。



到2016年,互动直播的爆发势不可挡,这个曾经古老而细分的领域突然站上了巅峰。直播平台超过了200家(获得融资的100+),直播用户超过2亿(月活5000万+),直播APP日均启动次数3~5次,人均日访问时长超过20分钟,直播市场的火爆也让直播相关的数据呈海量式井喷增长。我们可以做一道计算题,假设一家CDN网络有5000台服务器承载直播,每台机器上有3000个观看连接,1个连接跑1天产生的日志在1M左右,那么整个网络运行1天就有近15TB的日志数据产生(这在整个直播量中还是极小比例)。如果用户投诉卡、观看不了、推流不成功、延时大等等,运维要从这海量日志中找到某台机器上某条流的日志,如果没有一套高效的大数据平台就等同于大海捞针。再如,当前很多直播平台都出现了单场直播并发高达数百万规模,要从这几百万的连接数据中,实时获取到观众地域分布、终端类型、有多少人分享到朋友圈,有多少人点了广告链接等,这些都依赖于实时大数据分析。互动直播,正在进入大数据时代!


市场的火爆以及直播业务的新形势对直播技术提出了前所未有的挑战,秒开、低延时、低卡顿率、多终端适配等指标成为了直播技术提供商的竞争PK点。然而,看似简单的一键直播背后却涉及了极为复杂的技术流程,采集→推流源站→多层分发多屏播放 任何一个环节出现哪怕是网络抖动这么一个细小问题都有可能导致直播的卡顿甚至中断,而任何一次直播故障(尤其是主播推流)影响的都可能是上万人的互动体验。新兴的互动直播,上行推流并发高、分布散;主播端的网络环境、行为不可控;推播流的网络、终端碎片化严重,这些特点使得要保障每一条直播流都不出问题变得几乎不可能。所以,我们在追求秒开、低延时极致体验的同时,稳定的流畅度和快速定位、排查、恢复故障的能力也许更为重要。而这,却是当前所有CDN、视频云提供商最心知肚明的痛!



2

BMS可追溯日志,直播大数据平台的起点


要获得直播流的完整日志数据,需要从采集 → 推流 → 上行 → 源站 → 下行 → 播放 进行全链路日志采集。观止云以往文章《建设一套直播CDN到底有多难?》一文中曾讨论过直播分发与图文、点播分发最大的不同就在于需要专门的流媒体服务器来承载,该文也专门阐述了观止云BMS作为互动直播新形势下直播CDN最佳选择的极为重要一点就是,观止云BMS日志结构的设计最初就考虑到了完美支持大数据平台。


观止云《可追溯日志:视频云时代的新运维大胸器》一文中详细介绍了BMS的可追溯日志,首先它是基于连接的日志,并且将每条直播流在整个多层分发网络中的所有连接都会被赋予ID号,基于这些ID号,推流或是播流客户端就能拿到上层服务器的ID,上层又能拿到上上层ID,这样不论是从播流开始追溯,还是推流开始,或者是从整条流路径中任何一个节点均可快速追溯出任何直播流完整分发路径的日志数据。基于连接的可追溯日志,使得BMS彻底改变了FMS、crtmpd、Nginx-rtmp等流媒体服务器日志在可读性可用性方面的局面,也是能够支撑起直播大数据平台的起点与核心。

  • 《建设一套直播CDN、直播平台到底有多难?》本文介绍了观止云BMS能够作为新一代直播CDN系统的种种优势

  • 观止云技术实践| 可追溯日志:视频云时代的新运维大胸器本文详细介绍了观止云BMS可追溯日志的格式与运行流程

  • 全民大直播,流媒体选择Nginx是福还是祸?本文对比了BMS与FMS、crtmpd、Nginx-rtmp等流媒体服务器日志格式


3

基于海量日志的直播大数据平台


下图为观止云直播大数据平台结构图:



包括推流SDK、观止云编码器、多层CDN中的BMS、播放器、播流SDK、转码集群、录制集群等在内的所有直播云相关系统均向大数据平台汇报实时数据与连接信息,观止云大数据平台目前分为计费信息和实时大数据分析两大模块,主要应用于:

①快速运维,毫秒级定位直播故障;

②智能路由,真正解决直播流畅度问题;

③决策支撑,业务层实时大数据分析 三方面。

本文以实例方式介绍观止云大数据平台在快速运维方面的应用,后续文章会专门讨论其它方面的应用。


4

60毫秒,从海量日志中实时定位故障


假设以一个观众无法观看直播为例(推流流程相同),如果该观众是通过SRS播放器观看,那么只需将播放器显示的该播放流一组ID号(EDGE_IP,该进程ID_Pid,该连接会话ID_Cid)给到运维,运维人员在观止云大数据平台内输入改组ID号,60毫秒,就拿到了该条流从播放器→边缘→上层边缘→源站→推流器 完整路径的日志数据,这种毫秒级别从海量的N台机器的M个连接中找到目标连接日志的能力,才是大直播时代需要的响应速度。





从上图完整链路日志中,我们能获取到以下信息:

  • BMS日志的级别,trace(重要的日志)是白色,warn(警告日志)是黄色,error(错误日志)是红色。一般只有trace日志说明没有发现异常;

  • 该条流从播放器一直追溯到推流器的完整路径所经过的所有节点;

  • 该条流的从观止云动态配置系统Bitch中获取到的业务配置信息;

  • 途径所有节点的负载、收发数据、延时、丢包等;

  • 推流端网络、编码参数等信息。


运维人员在毫秒级别获取到完整链路日志后,从这些可读性较强的日志中,一般也会在1分钟之内定位到直播故障。


如果没有使用观止云播放器,当出现上述观看不了或者推流不成功的问题后,运维人员在观止云Debugger系统中快速创建排错任务,生成对应链接。该用户只需在浏览器中打开此链接,Debugger系统将自动拿到该条流的ID号组,并自动检索出上述完整链路日志,该功能也被应用在问题重现上面(该功能即将在观止直播云开放,云平台用户可自行创建类似排错任务)。



以上是已经出了问题,运维人员可以毫秒级排错。事实上,观止云CDN所有环节都在将数据实时上报大数据平台,通过设定错误类别以及报警规则,海量的服务数据将实现自动报警,这样运维就能先于客户发现并解决问题了。

Fast Query Connection Log


主动汇报日志数据


END


除了本文讨论的毫秒级运维排错外,大数据的应用还有望真正解决直播卡顿率这个问题。观止云正在建设的应用层智能路由网络(BAR)将一改传统CDN根据上层去回源这一网络模型,它将基于实时大数据决策系统,组合例如设备负载、吞吐、抖动、延时、丢包等等综合因子,从复杂的全网链路中动态决策出最优分发线路。这些只是已经在着手做的,未来,大数据与互动直播或许还会在更多方面擦出猛烈的火花。


责任编辑 / 观止云PM羌人彧

观止云致力于打造最专业的运营级视频云平台,现招募以下才俊加盟:

运维:有CDN、视频行业运维经验优先,Linux操作,shell、python等等语言不在话下,沟通能力强。

研发(服务器/大数据/编码器)、售前、销售等岗位OPEN中,请发送简历至邮箱:hr@bravovcloud.com

 

观止云公众号历史文章中有大规模P2P商用数据、全球主流流媒体服务器功能性能对比、编码器等大量技术文章介绍,有网络直播市场、技术方案等介绍,请在【往期内容】栏目中查看。想要了解更多观止云业务介绍,请点击【阅读原文】

0 0
原创粉丝点击