2018年世界杯网络直播，网络同时在线观看人数超过千万，为了保证直播体验，CDN在其中起到了极其重要的作用，为了保障CDN的播放质量，需要对CDN的各类日志进行实时收集、清洗和分析。我们以类似“世界杯”直播为背景，向大家演示如何通过CDN的播放器、推流等日志实时分析，监控线上业务的质量，了解用户的分布与习惯，构建数字化的运维与运营分析平台。
CDN日志系统通用架构
首先，介绍一下世界杯直播，简化的数据流向：
- 直播流推送至视频直播中心
- 直播中心处理之后，视频数据推送到CDN节点
- 用户通过app或网页播放刚上传至CDN节点的内容
CDN实时日志系统，通常有以下几部分构成：
- 数据实时采集 : 在直播推流、播放期间，都会产生大量日志，需要在秒级延时内，实时采集这些日志到日志中心。
- 数据清洗：日志采集后，对数据进行清洗，以满足不同场景的处理需求（如，对不同域名日志的定制化分析）。
-
数据处理和存储 : 对于不同的应用场景，数据的处理和存储方式也不尽相同 :
- 实时处理 : 在秒级别对海量数据进行实多维度聚合统计分析
- 表格存储 : 实时统计后的各类监控指标
- 对象存储 : 日志打包压缩，供用户离线下载
- 数据仓库 : 数据离线分析、用户行为分析、物业报表等场景
日志系统涉及的平台
从整个架构上来说，整个CDN日志分析涉及的环节多，对服务质量也有严苛的要求，依赖的各系统也足够庞大，技术挑战大：
- 日志采集系统 : 实时从全球多个区域、数万节点采集日志，数据产生后秒级延时内采集至日志中心，通常延时不能超过1分钟，否则日志的实时价值大打折扣。每天都有千亿、万亿的日志需要7*24小时不间断采集，同时也要考虑各类流量高峰等对系统产生的巨大冲击。
- 流计算系统 : 为了满足报警等实时性要求高的场景，流计算系统在毫秒~秒级时间内，就需要对海量的日志进行实时、多维度的分析，同时对于部分数据，还有大量个性化定制的需求，数据处理组合维度大大增加，计算复杂度也响应增加。
- 存储平台：为满足不同的应用场景，数据的读取特点也不同，如果保存metric指标的NoSql系统（TableStore），可保证各metric读取延时小于10ms；保存日志供用户下载的对象存储系统（Oss），则提供数据高吞吐下载能力；复杂的分析场景，可由数仓系统来支持。
- 报警系统：在CDN场景下，对服务的可用性、性能要求苛刻，需要对于各类异常进行实时、准确的报警，这就需要依赖可靠的监控报警系统。
普通CDN用户面临的困境
从上面介绍的整套CDN日志分析流程中，使用依赖多套子系统，任意一个系统要做好都不是一件容易的事情，需要投入大量的时间和资源。而对于用户来说，对于CDN日志也有数据实时、离线的分析的需求，我们先看看普通CDN用户在满足这方面需求上有哪些困境：
- 用户无数据 : CDN的访问日志，在由各大CDN产商上产生，用户不可直接获取。现阶段，绝大部分的CDN产商都只提供离线日志下载，日志数据从产生，到用户可下载，需要几十分钟到数个小时不等。这样大的数据产生延时，大大削减了实时流处理、报警等高实时性要求场景的分析价值。
- 多种分析需求：为了解决各类定制化的分析需求，通常的做法是搭建和运维开源系统，如，用于做数据通道的kafka、流式分析的storm或flink、做数据分析的spark、hadoop等。
- 可视化需求： 对于最终的分析结果的展示，依赖数据库（结果集小）、HBase（结果集大）存储结果，再通过对接各可视化工具来完成。
从上面的介绍来看，对于普通用户，要对CDN日志进行实时、离线分析真不是一件简单的事情，搭建、运维和管理哥依赖系统本身就不是一件容易的事情，为了完成需求，有时还需要编写不少代码，但最终并不一定能得到很好的效果（如数据延时问题不能解决）。那有没有更好的解决办法么？
CDN日志一站式解决方案
阿里云日志服务和CDN，将于9月推出CDN日志实时分析一站式解决方案，CDN日志产生后，在小于60秒的时间内，直接投递至阿里云日志服务，之后，直接使用日志服务提供的实时、交互式分析和报表展示功能，对CDN日志进行实时分析，大大简化整个流程。
日志服务简介
在介绍该方案之前，先简单介绍一下日志服务，我们希望日志服务能够让用户远离日志分析中的各类繁杂“琐事”，更加专注于和业务更紧密、更有价值的数据“分析”上。日志服务提供主要3个功能：
- 实时采集与消费(Log Hub) : 通过ECS、容器、移动端，开源软件，JS等接入实时日志数据（例如Metric、Event、BinLog、TextLog、Click等）；提供实时消费接口，与实时计算及服务对接。
- 投递数仓（Log Shipper)：稳定可靠的日志投递。将日志中枢数据投递至存储类服务进行存储。支持压缩、自定义Partition、以及行列等各种存储方式。
-
查询与实时分析（Search/Analytics）: 实时索引、查询分析数据数据。
- 查询：关键词、模糊、上下文、范围
- 统计：SQL聚合等丰富查询手段
- 可视化：Dashboard + 报表功能
- 对接：Grafana，JDBC/SQL92
接下来，我们介绍一下在直播场景下,CDN日志实时投递只日志服务之后，可以做哪些典型的实时分析：
典型场景：直播推流
直播推流数据非常重要，当有了直播推流的日志之后，可掌控推流端各种实时状态：
- 推流概览 : 实时知道当前的推流数量、各个推流的流量和速度、从各省、运营商维度统计
- 推流质量：多维度的推流质量统计、重点推流的实时质量监控
- 错误根源追踪：快速定位错误产生的源头（直播源、服务端、客户端、运营商）
下图是直播推流的各项监控统计，从整体的推流质量上来看，99%以上的推流都是正常的，说明推流的质量非常好。
下表统计了各类错误的产生原因，可以看到最大的错误来源是客户端主动断开。
典型场景：CDN下行
介绍完直播推流端，我们再看看播放端（CDN下行）。CDN下行是用户直接接触，其质量直接决定用户观看体验，在下行日志中，我也可以从多个维度进行分析：
-
整体质量：
- 健康度 : 在所有的访问中，有多少请求是成功的
- Cache命中率 : 命中率越高，用户访问延时越低，体验越好
- 下载速度 : 这也是关系到播放质量的重要因素
-
多维度分析：
- top域名访问次数、流量 : 重点域名的访问质量
- 地域、运营商统计：各个链路的质量
- 下载量、速度、延时：多项关键指标
-
错误诊断：
- 实时错误QPS、比例 : 整体错误情况
- 错误Top 域名、URI : 错误是否和自身相关
- 错误Top 地域、运营商 : 错误是否和外部因素相关
- 错误客户端分别 : 是否是新发布版本引入的问题
在下图中，可以看到，绝大部分错误，都是发生在这个客户端版本，就需要怀疑是不是新的版本发布带来的呢？
典型场景：用户行为分析
用户的访问行为，最终可体现在日志上，通过日志的分析，了解到用户是如何进行访问的，哪些资源是热门资源，通过用户的来源，更清楚了解用户来源，以后的运营推广也可以更具有针对性，除此之外，对异常IP进行监控，可更早发现异常，如高频访问的IP，是否存在爬取数据的嫌疑。
Demo演示：
当系统出现报警或有用户投诉的情况下，通用的处理流程往往是相似的：
- 整体概述：整体访问是否正常？
- 缩小范围：是局部错误么，是哪个域名，或是哪个区域，再或者只是某个用户？
- 精准定位：缩小调查范围后，可对局部数据进行同比、环比的对比；观察更详细的日志；多个维度进行Adhoc的query分析。
在这个过程中，我们可以发现，整个分析流程，是从上到下、从面到点、交互式的分析，涉及到Drill Down/Roll Up等多方面。因此，灵活和方便是系统必备的两项。在以下的视频中，展示如何在日志服务中，对CDN日志进行交互式的分析。
另外，我们也提供了一个Demo，可以实际体验一下Mock的CDN日志分析： Demo连接
