大數據驅動業務決策，CDN實時日誌重磅上線

摘要： 阿里雲CDN上線了實時日誌功能，打通日誌服務(SLS)的能力，將CDN採集的實時日誌，在小於60秒的時間內投遞至日誌服務，進行實時、交互式分析和報表呈現。經過CDN日誌的實時分析，能夠快速的發現和定位問題，進而對日誌數據的挖掘，提升數據的決策能力，將業務推向一個新的高度。

背景

CDN是很是重要的互聯網基礎設施，用戶能夠經過CDN，快速的訪問網絡中各類圖片，視頻等資源。在訪問過程當中，CDN會產生大量的日誌數據，而隨着現在愈來愈複雜的網絡環境變化，和業務的迅速增加，日誌數據變得更大量、更多維度。這些數據一般都與用戶的下一步業務決策息息相關。

在與CDN用戶的溝通中，咱們發現一般用戶會面臨如下困境：

• 用戶無數據 : CDN的訪問日誌，由各大CDN產商上產生，用戶不可直接獲取。現階段，絕大部分的CDN產商都只提供離線日誌下載，日誌數據從產生，到用戶可下載，須要幾十分鐘到數個小時不等。這樣大的數據產生延時，大大削減了實時流處理、報警等高實時性要求場景的分析價值。

• 多種分析需求：爲了解決各種定製化的分析需求，一般的作法是搭建和運維開源系統，如用於作數據通道的kafka、流式分析的storm或flink、作數據分析的spark、hadoop等。

• 可視化需求：對於最終的分析結果的展現，依賴數據庫（結果集小）、HBase（結果集大）存儲結果，再經過對接各可視化工具來完成。

綜上所述，更實時地、詳細地關注和分析日誌的需求逐漸顯露，可是普通用戶對CDN日誌進行實時、離線分析又並不容易，須要付出搭建、運維和管理成本，爲了完成需求，有時還須要編寫很多代碼，但最終並不必定能獲得很好的效果。整個CDN實時日誌涉及的環節多，對服務質量也有嚴苛的要求，技術挑戰比較大。那有沒有更好的解決辦法麼？

CDN實時日誌一站式解決方案上線

近期，阿里雲CDN上線了實時日誌功能，打通日誌服務(SLS)的能力，將CDN採集的實時日誌，在小於60秒的時間內投遞至日誌服務，進行實時、交互式分析和報表呈現。經過CDN日誌的實時分析，能夠快速的發現和定位問題，進而對日誌數據的挖掘，提升數據的決策能力，將業務推向一個新的高度。點擊跳轉CDN實時日誌專題頁，瞭解功能詳情。

CDN實時日誌服務與日誌下載的區別

CDN實時日誌爲實時採集的日誌數據，日誌數據延遲平均不超過30秒。同時，CDN打通了日誌服務分析的能力，爲客戶定製4張分析報表，可快速對日誌進行分析，發現問題，及時決策。而CDN提供的離線日誌下載，只能下載4小時前的每小時日誌數據。

CDN實時日誌系統中簡化的數據流向以下圖構成：

• 數據實時採集 : 在直播推流、播放期間，都會產生大量日誌，須要在秒級延時內，實時採集這些日誌到日誌中心。

• 數據清洗：日誌採集後，對數據進行清洗，以知足不一樣場景的處理需求（如，對不一樣域名日誌的定製化分析）。

• 數據處理和存儲 : 對於不一樣的應用場景，數據的處理和存儲方式也不盡相同 。

1. 實時處理 : 在秒級別對海量數據進行實多維度聚合統計分析。
2. 表格存儲 : 實時統計後的各種監控指標。
3. 對象存儲 : 日誌打包壓縮，供用戶離線下載。
4. 數據倉庫 : 數據離線分析、用戶行爲分析、物業報表等場景。

CDN實時日誌的價值

1. 實時

傳統的日誌分析模式，須要您將日誌下載後，從新上傳至數據倉庫，在數據倉庫進行一系列的清洗和數據模型定義後，再進數據分析，這個過程須要維護的人力較多，時間較長。

CDN實時日誌能夠從全球多個區域、數萬節點實時採集日誌，一般延時不超過60秒，不然日誌的實時價值大打折扣。同時，在開通服務後，CDN將日誌數據自動投遞到日誌服務(SLS)，免去繁瑣的傳統日誌分析的流程，實時查看日誌分析結果。

2. 無需寫代碼，無需運維

前面也提到，想要自行搭建日誌系統，解決業務定製化的需求，開發、運維、管理的成本是比較高的，接入CDN實時日誌系統，可讓開發者迴歸業務的創新和性能自己，減小沒必要要的投入。

3. 多維度SQL分析，秒級10億+規模

CDN實時日誌系統支持天天千億、萬億的日誌7*24小時不間斷採集，並實時對海量日誌進行多維度分析，流計算系統在毫秒級。讓用戶遠離日誌分析中的各種繁雜「雜事」，更加專一於和業務更緊密、更有價值的數據「分析」上。

同時，實時日誌能夠輕鬆應對數據處理組合維度大、計算複雜度大、各種流量高峯衝擊等業務場景。保存日誌供用戶下載的對象存儲系統（Oss）可提供數據高吞吐下載能力，複雜的分析場景，可由數倉系統來支持。

4. 數據可視化及大數據挖掘

最終分析結果的展現也很是關鍵，CDN實時日誌能夠爲用戶提供基於業務的可視化報表服務，用戶可輕鬆地掌控業務健康度、緩存命中率、平均下載速度、流量狀況、網速、運營商、延時分佈等數據。

5.日誌、監控、告警聯動的一站式解決方案

在CDN場景下，對服務的可用性、性能要求苛刻，須要對於各種異常進行實時、準確的報警，這就須要依賴可靠的監控報警系統。CDN日誌系統將來將和監控、告警、處理機制聯動，自動化的解決常規問題，縮短業務故障的時間，避免用戶損失。

5、典型應用場景

1. 直播推流

在直播場景下，CDN日誌實時投遞至日誌服務以後，能夠作幾個典型的實時分析。

直播推流數據很是重要，當有了直播推流的日誌以後，可掌控推流端各類實時狀態：

• 推流概覽 : 實時知道當前的推流數量、各個推流的流量和速度、從各省、運營商維度統計
• 推流質量：多維度的推流質量統計、重點推流的實時質量監控
• 錯誤根源追蹤：快速定位錯誤產生的源頭（直播源、服務端、客戶端、運營商）

下圖是直播推流的各項監控統計，從總體的推流質量上來看，99%以上的推流都是正常的，說明推流的質量很是好。

下表統計了各種錯誤的產生緣由，能夠看到最大的錯誤來源是客戶端主動斷開。

2.CDN下行

播放端（CDN下行）是用戶直接接觸，其質量直接決定用戶觀看體驗，在下行日誌中，我也能夠從多個維度進行分析：

• 總體質量：
健康度 : 在全部的訪問中，有多少請求是成功的
Cache命中率 : 命中率越高，用戶訪問延時越低，體驗越好
下載速度 : 這也是關係到播放質量的重要因素

• 多維度分析：
top域名訪問次數、流量 : 重點域名的訪問質量
地域、運營商統計：各個鏈路的質量
下載量、速度、延時：多項關鍵指標

• 錯誤診斷：
實時錯誤QPS、比例 : 總體錯誤狀況
錯誤Top 域名、URI : 錯誤是否和自身相關
錯誤Top 地域、運營商 : 錯誤是否和外部因素相關
錯誤客戶端分別 : 是不是新發布版本引入的問題

在下圖中，能夠看到，絕大部分錯誤，都是發生在這個客戶端版本，就須要懷疑是否是新的版本發佈帶來的呢？

3.用戶行爲分析

用戶的訪問行爲，最終可體如今日誌上，經過日誌的分析，瞭解到用戶是如何進行訪問的，哪些資源是熱門資源，經過用戶的來源，更清楚瞭解用戶來源，之後的運營推廣也能夠更具備針對性，除此以外，對異常IP進行監控，可更早發現異常，如高頻訪問的IP，是否存在爬取數據的嫌疑。

Demo演示：

當系統出現報警或有用戶投訴的狀況下，通用的處理流程每每是類似的：

• 總體概述：總體訪問是否正常？
• 縮小範圍：是局部錯誤麼，是哪一個域名，或是哪一個區域，再或者只是某個用戶？
• 精準定位：縮小調查範圍後，可對局部數據進行同比、環比的對比；觀察更詳細的日誌；多個維度進行Adhoc的query分析。

在這個過程當中能夠發現，整個分析流程，是從上到下、從面到點、交互式的分析，涉及到Drill Down/Roll Up等多方面。所以，靈活和方即是系統必備的兩項。在如下的視頻中，展現如何在日誌服務中，對CDN日誌進行交互式的分析。

另外，咱們也提供了一個Demo，能夠實際體驗一下Mock的CDN日誌分析：Demo鏈接

6、接入流程

目前實時日誌功能已經在CDN控制檯上線，用戶能夠經過簡單操做，快速的、無障礙的使用CDN實時日誌的能力。主要步驟以下：

1. 登陸CDN控制檯。
2. 在左側導航欄，單擊日誌。
3. 在日誌頁，單擊實時日誌推送。
4. 單擊一鍵建立日誌服務。
5. 配置Project、Logstore、地域等信息，而後單擊下一步。
6. 選擇關聯域名並綁定，而後單擊建立。

7、計費方式與活動

一般，實時日誌按照推送成功條數，每萬條0.06元進行付費，該費用已經包含日誌服務分析的費用。所以，在必定使用邊界內，您無需支付任何的日誌服務費用。

可是在如下狀況下，您還須要支付日誌服務的費用：
1．日誌存儲超過7天的存儲部分，由日誌服務單獨收費。
2．日誌服務的外網讀寫費用。

原文連接