世界杯直播背后的实时日志分析

  1. 云栖社区>
  2. 阿里云存储服务>
  3. 博客>
  4. 正文

世界杯直播背后的实时日志分析

suntingtao 2018-09-09 17:49:19 浏览1472

2018年世界杯网络直播,网络同时在线观看人数超过千万,为了保证直播体验,CDN在其中起到了极其重要的作用,为了保障CDN的播放质量,需要对CDN的各类日志进行实时收集、清洗和分析。我们以类似“世界杯”直播为背景,向大家演示如何通过CDN的播放器、推流等日志实时分析,监控线上业务的质量,了解用户的分布与习惯,构建数字化的运维与运营分析平台。

CDN日志系统通用架构

首先,介绍一下世界杯直播,简化的数据流向:

  • 直播流推送至视频直播中心
  • 直播中心处理之后,视频数据推送到CDN节点
  • 用户通过app或网页播放刚上传至CDN节点的内容

image.png | left | 747x418

CDN实时日志系统,通常有以下几部分构成:

  • 数据实时采集 : 在直播推流、播放期间,都会产生大量日志,需要在秒级延时内,实时采集这些日志到日志中心。
  • 数据清洗:日志采集后,对数据进行清洗,以满足不同场景的处理需求(如,对不同域名日志的定制化分析)。
  • 数据处理和存储 : 对于不同的应用场景,数据的处理和存储方式也不尽相同 :

    • 实时处理 : 在秒级别对海量数据进行实多维度聚合统计分析
    • 表格存储 : 实时统计后的各类监控指标
    • 对象存储 : 日志打包压缩,供用户离线下载
    • 数据仓库 : 数据离线分析、用户行为分析、物业报表等场景

日志系统涉及的平台

image.png | left | 747x420

从整个架构上来说,整个CDN日志分析涉及的环节多,对服务质量也有严苛的要求,依赖的各系统也足够庞大,技术挑战大:

  • 日志采集系统 : 实时从全球多个区域、数万节点采集日志,数据产生后秒级延时内采集至日志中心,通常延时不能超过1分钟,否则日志的实时价值大打折扣。每天都有千亿、万亿的日志需要7*24小时不间断采集,同时也要考虑各类流量高峰等对系统产生的巨大冲击。
  • 流计算系统 : 为了满足报警等实时性要求高的场景,流计算系统在毫秒~秒级时间内,就需要对海量的日志进行实时、多维度的分析,同时对于部分数据,还有大量个性化定制的需求,数据处理组合维度大大增加,计算复杂度也响应增加。
  • 存储平台:为满足不同的应用场景,数据的读取特点也不同,如果保存metric指标的NoSql系统(TableStore),可保证各metric读取延时小于10ms;保存日志供用户下载的对象存储系统(Oss),则提供数据高吞吐下载能力;复杂的分析场景,可由数仓系统来支持。
  • 报警系统:在CDN场景下,对服务的可用性、性能要求苛刻,需要对于各类异常进行实时、准确的报警,这就需要依赖可靠的监控报警系统。

普通CDN用户面临的困境

从上面介绍的整套CDN日志分析流程中,使用依赖多套子系统,任意一个系统要做好都不是一件容易的事情,需要投入大量的时间和资源。而对于用户来说,对于CDN日志也有数据实时、离线的分析的需求,我们先看看普通CDN用户在满足这方面需求上有哪些困境:

image.png | left | 747x418

  • 用户无数据 : CDN的访问日志,在由各大CDN产商上产生,用户不可直接获取。现阶段,绝大部分的CDN产商都只提供离线日志下载,日志数据从产生,到用户可下载,需要几十分钟到数个小时不等。这样大的数据产生延时,大大削减了实时流处理、报警等高实时性要求场景的分析价值。
  • 多种分析需求:为了解决各类定制化的分析需求,通常的做法是搭建和运维开源系统,如,用于做数据通道的kafka、流式分析的storm或flink、做数据分析的spark、hadoop等。
  • 可视化需求: 对于最终的分析结果的展示,依赖数据库(结果集小)、HBase(结果集大)存储结果,再通过对接各可视化工具来完成。
    从上面的介绍来看,对于普通用户,要对CDN日志进行实时、离线分析真不是一件简单的事情,搭建、运维和管理哥依赖系统本身就不是一件容易的事情,为了完成需求,有时还需要编写不少代码,但最终并不一定能得到很好的效果(如数据延时问题不能解决)。那有没有更好的解决办法么?

CDN日志一站式解决方案

阿里云日志服务和CDN,将于9月推出CDN日志实时分析一站式解决方案,CDN日志产生后,在小于60秒的时间内,直接投递至阿里云日志服务,之后,直接使用日志服务提供的实时、交互式分析和报表展示功能,对CDN日志进行实时分析,大大简化整个流程。

image.png | left | 747x417

日志服务简介

在介绍该方案之前,先简单介绍一下日志服务,我们希望日志服务能够让用户远离日志分析中的各类繁杂“琐事”,更加专注于和业务更紧密、更有价值的数据“分析”上。日志服务提供主要3个功能:

  • 实时采集与消费(Log Hub) : 通过ECS、容器、移动端,开源软件,JS等接入实时日志数据(例如Metric、Event、BinLog、TextLog、Click等);提供实时消费接口,与实时计算及服务对接。
  • 投递数仓(Log Shipper):稳定可靠的日志投递。将日志中枢数据投递至存储类服务进行存储。支持压缩、自定义Partition、以及行列等各种存储方式。
  • 查询与实时分析(Search/Analytics): 实时索引、查询分析数据数据。

    • 查询:关键词、模糊、上下文、范围
    • 统计:SQL聚合等丰富查询手段
    • 可视化:Dashboard + 报表功能
    • 对接:Grafana,JDBC/SQL92

image.png | left | 747x420

接下来,我们介绍一下在直播场景下,CDN日志实时投递只日志服务之后,可以做哪些典型的实时分析:

典型场景:直播推流

直播推流数据非常重要,当有了直播推流的日志之后,可掌控推流端各种实时状态:

  • 推流概览 : 实时知道当前的推流数量、各个推流的流量和速度、从各省、运营商维度统计
  • 推流质量:多维度的推流质量统计、重点推流的实时质量监控
  • 错误根源追踪:快速定位错误产生的源头(直播源、服务端、客户端、运营商)

image.png | left | 747x419

下图是直播推流的各项监控统计,从整体的推流质量上来看,99%以上的推流都是正常的,说明推流的质量非常好。

image.png | left | 747x418

下表统计了各类错误的产生原因,可以看到最大的错误来源是客户端主动断开。

image.png | left | 747x297

典型场景:CDN下行

介绍完直播推流端,我们再看看播放端(CDN下行)。CDN下行是用户直接接触,其质量直接决定用户观看体验,在下行日志中,我也可以从多个维度进行分析:

  • 整体质量:

    • 健康度 : 在所有的访问中,有多少请求是成功的
    • Cache命中率 : 命中率越高,用户访问延时越低,体验越好
    • 下载速度 : 这也是关系到播放质量的重要因素
  • 多维度分析:

    • top域名访问次数、流量 : 重点域名的访问质量
    • 地域、运营商统计:各个链路的质量
    • 下载量、速度、延时:多项关键指标
  • 错误诊断:

    • 实时错误QPS、比例 : 整体错误情况
    • 错误Top 域名、URI : 错误是否和自身相关
    • 错误Top 地域、运营商 : 错误是否和外部因素相关
    • 错误客户端分别 : 是否是新发布版本引入的问题

image.png | left | 747x412

image.png | left | 747x418

在下图中,可以看到,绝大部分错误,都是发生在这个客户端版本,就需要怀疑是不是新的版本发布带来的呢?

image.png | left | 747x419

典型场景:用户行为分析

用户的访问行为,最终可体现在日志上,通过日志的分析,了解到用户是如何进行访问的,哪些资源是热门资源,通过用户的来源,更清楚了解用户来源,以后的运营推广也可以更具有针对性,除此之外,对异常IP进行监控,可更早发现异常,如高频访问的IP,是否存在爬取数据的嫌疑。

image.png | left | 747x405

image.png | left | 747x420

Demo演示:

当系统出现报警或有用户投诉的情况下,通用的处理流程往往是相似的:

  • 整体概述:整体访问是否正常?
  • 缩小范围:是局部错误么,是哪个域名,或是哪个区域,再或者只是某个用户?
  • 精准定位:缩小调查范围后,可对局部数据进行同比、环比的对比;观察更详细的日志;多个维度进行Adhoc的query分析。

image.png | left | 747x411

在这个过程中,我们可以发现,整个分析流程,是从上到下、从面到点、交互式的分析,涉及到Drill Down/Roll Up等多方面。因此,灵活和方便是系统必备的两项。在以下的视频中,展示如何在日志服务中,对CDN日志进行交互式的分析。


另外,我们也提供了一个Demo,可以实际体验一下Mock的CDN日志分析:Demo连接