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連接配接