[封萬里 王之偉 池慶國 孫志惠 岑翼剛]

1 引言

CDN，全稱內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network）[1]，可以簡單地將其理解成一個離客戶很近的、可以從上面獲取到完整的原始數(shù)據(jù)的服務(wù)器，它會定期和擁有原始內(nèi)容的服務(wù)器進(jìn)行同步，保證用戶可以從上面獲取到最新的內(nèi)容。

對于大規(guī)模的CDN運(yùn)營商網(wǎng)絡(luò)來說，邊緣節(jié)點[2]作為一級緩存部署在全國各地，用來響應(yīng)用戶的請求，如果用戶訪問的資源直接命中邊緣節(jié)點，則直接返回響應(yīng)，否則請求會進(jìn)入內(nèi)容中心節(jié)點[3]。內(nèi)容中心節(jié)點往往是少數(shù)的，用來對邊緣節(jié)點未命中的請求進(jìn)行集中處理，如果內(nèi)容中心未命中，用戶請求則直接進(jìn)入源站。上述流程的鏈路如圖1所示。

圖1 CDN服務(wù)的請求鏈路

中國移動CDN網(wǎng)絡(luò)目前在全國擁有約1 800個邊緣節(jié)點以及上海、北京兩個內(nèi)容中心。

邊緣節(jié)點與內(nèi)容中心節(jié)點在用戶訪問高峰期時段常出現(xiàn)命中率偏低、響應(yīng)延遲偏大的現(xiàn)象，大大影響了用戶體驗。為了及時排查故障，CDN運(yùn)維人員需要登錄具體的節(jié)點服務(wù)器查看用戶的訪問日志并分析網(wǎng)絡(luò)原因。一條完整的用戶請求鏈條較長、用戶日志量較大、各個環(huán)節(jié)的關(guān)聯(lián)性較強(qiáng)，這些都給運(yùn)維人員的人工分析工作帶來很大的困難。本文設(shè)計并開發(fā)了一套全鏈路分析系統(tǒng)，借助大數(shù)據(jù)存儲引擎與搜索引擎，將日志分析工作完全自動化，效率與準(zhǔn)確性都得到了很大提升。下文詳細(xì)介紹系統(tǒng)結(jié)構(gòu)圖。

2 本文方案

本文所提出的系統(tǒng)分為日志收集、日志檢索、故障自動分析、人工修正4個模塊；各個模塊都提供獨(dú)立的系統(tǒng)服務(wù)，互不干擾，在生產(chǎn)環(huán)境中避免了模塊互相干擾造成的服務(wù)不可用問題；系統(tǒng)的使用者為CDN運(yùn)維人員。

2.1 日志收集

該模塊分為兩個子模塊，分別負(fù)責(zé)日志的采集與落盤保存，均是采用開源的數(shù)據(jù)加工工具進(jìn)行操作，下面詳細(xì)介紹各個模塊的實現(xiàn)。

2.1.1 日志采集

結(jié)合引言中所述的用戶請求的各個環(huán)節(jié)，CDN網(wǎng)絡(luò)會產(chǎn)生4種類型的日志，分別是：邊緣節(jié)點訪問日志、邊緣節(jié)點緩存日志、內(nèi)容中心訪問日志和內(nèi)容中心緩存日志。這些日志由部署在邊緣節(jié)點、內(nèi)容中心節(jié)點上的Filebeat、Logstash組件負(fù)責(zé)收集用戶日志并傳送至專用的FTP服務(wù)器[4]，并以文件的形式保存。當(dāng)前業(yè)界還有Flume等日志采集工具[5]，用戶可以根據(jù)使用場景靈活選擇。

2.1.2 日志存儲

上一步文件里的日志由FTP上的應(yīng)用負(fù)責(zé)定時導(dǎo)入Hive集群[6]。Hive腳本先進(jìn)行簡單指標(biāo)的計算，如下載速率、首字節(jié)時延等，再由另一個定時任務(wù)將Hive里的數(shù)據(jù)定時導(dǎo)入ES集群[7]。Hive與ES集群共機(jī)部署，這大大緩解了不同組件之間由于網(wǎng)絡(luò)質(zhì)量造成的高時延、低可用問題。

目前中國移動的FTP服務(wù)器集群位于北京與上海，分別負(fù)責(zé)收集北方省份與南方省份的日志。相應(yīng)地，Hive集群與ES集群也有兩個?？紤]到日志查詢接口只部署在上海的機(jī)房，將北京與上海的ES集群設(shè)置成跨集群[8]服務(wù)，達(dá)到的效果是：部署在上海的應(yīng)用可以檢索到北京ES集群的數(shù)據(jù)，數(shù)據(jù)通過公網(wǎng)傳輸，同時兩個集群均設(shè)置了密碼，保障了數(shù)據(jù)跨公網(wǎng)傳輸?shù)陌踩?。?shù)據(jù)在組件間的流向如圖2所示。

圖2 本文方案的數(shù)據(jù)流向

Hive在數(shù)據(jù)流程圖中起的作用是：有些字段需要基于原始字段進(jìn)行二次計算，如下載速率、首字節(jié)延時[9]分別是基于原始日志里的流量、請求開始時間、請求響應(yīng)時間等字段計算而來，所以Hive兼具存儲與計算引擎的兩大優(yōu)點，并將額外計算出的字段導(dǎo)入ES集群。

生產(chǎn)環(huán)境的數(shù)據(jù)量約每秒3萬條日志量，兩個ES集群的配置參數(shù)為：128 G內(nèi)存（其中分配給ES的內(nèi)存為32G）、32核，集群規(guī)模為6臺，其中Master節(jié)點有2個。實際使用中的數(shù)據(jù)導(dǎo)入延時小于5秒，ES集群的存儲周期為6個月。

2.2 日志檢索

日志檢索模塊包括高級檢索與日志溯源兩個子模塊，高級檢索即CDN運(yùn)維人員自定義條件查詢數(shù)據(jù)；日志溯源即原始日志的查詢與展示。

2.2.1 日志高級檢索

該子模塊支持用戶請求在整個鏈路中的日志關(guān)聯(lián)查詢，可以根據(jù)運(yùn)維人員填寫的日志檢索條件進(jìn)行邊緣節(jié)點訪問日志查詢，并將查詢結(jié)果以列表形式展示，具體展示哪些字段可以由運(yùn)維人員自行選擇。得益于ES底層基于倒排索引[10]的機(jī)制，查詢跨度為一個月的數(shù)據(jù)時響應(yīng)時間約600 ms。檢索條件包括：開始時間與結(jié)束時間/用戶IP/邊緣節(jié)點IP/資源下載速率大于或小于某一個給定數(shù)值/響應(yīng)狀態(tài)碼（支持多個狀態(tài)碼查詢）/用戶請求的域名/命中狀態(tài)。列表最后一列為“日志溯源”功能。

2.2.2 日志溯源

為了從源頭追溯用戶請求日志，本文從邊緣節(jié)點開始，對用戶訪問過程中的每個環(huán)節(jié)產(chǎn)生的日志增加一個字段 ”traceId”，含義為：鏈路ID，該ID在全網(wǎng)是唯一的。

日志溯源功能可以由運(yùn)維人員自行選擇查看四種類型的日志，每種日志的所需查看字段可獨(dú)立選擇，互不影響，點擊查詢后頁面會顯示用戶請求的完整鏈路圖，圖中的內(nèi)容包括。

（1）用戶IP；

（2）邊緣節(jié)點IP，若命中，則直接返回，否則進(jìn)入下一步；

（3）進(jìn)入內(nèi)容中心，若命中，則直接返回，否則進(jìn)入下一步；

（4）若命中，則直接返回，否則進(jìn)行回源。

圖3中的每個環(huán)節(jié)都會產(chǎn)生至少一條日志，原始日志有多個字段，為了給運(yùn)維人員更直觀地展示用戶在每個環(huán)節(jié)所產(chǎn)生日志的原始信息，由前端將原始日志緩存，運(yùn)維人員點擊“原始日志”標(biāo)簽時則可以看到詳細(xì)內(nèi)容。

圖3 用戶請求拓?fù)鋱D（分別對應(yīng)（2）、（3）、（4）描述的場景）

2.3 故障自動分析

該模塊可以根據(jù)指定條件下的日志及指標(biāo)自動分析故障原因，目前支持分析響應(yīng)狀態(tài)碼、首字節(jié)時延、下載速率3個指標(biāo)。系統(tǒng)首先基于ES的分桶與聚合[7]機(jī)制，根據(jù)用戶IP、請求IP等指標(biāo)分桶，生成用戶請求鏈路拓?fù)鋱D，基于生成的拓?fù)鋱D，系統(tǒng)的故障分析邏輯如下：

（1）節(jié)點服務(wù)狀態(tài)

分析每個節(jié)點的服務(wù)指標(biāo)和回源指標(biāo)。服務(wù)指標(biāo)包括：節(jié)點服務(wù)請求的狀態(tài)碼的數(shù)量及占比，狀態(tài)碼包含200、206、302、300、403、404、416、500、502、504、其他；響應(yīng)碼在2xx、3xx、4xx、5xx下首字節(jié)時延、下載速率和命中狀態(tài)分別的數(shù)量和占比。

（2）故障分析結(jié)果

系統(tǒng)預(yù)設(shè)3個閾值[9]，閾值為可配。

① 正常響應(yīng)狀態(tài)碼占比閾值，響應(yīng)狀態(tài)碼為正常值的占比閾值。若大于該閾值，則指標(biāo)正常，否則異常響應(yīng)狀態(tài)碼請求較多。

② 正常首字節(jié)時延占比閾值，首字節(jié)時延小于正常值的占比閾值。若大于該閾值，則指標(biāo)正常，否則首字節(jié)時延大的請求較多。

③ 正常下載速率占比閾值，下載速率大于正常值的占比閾值。若大于該閾值，則指標(biāo)正常，否則下載速率小的請求較多。

基于上述閾值直接展示故障分析后的匯總結(jié)果，描述客觀現(xiàn)象，結(jié)果以表格的形式展示，如圖4所示，用戶看起來更加直觀。

圖4 故障分析結(jié)果

2.4 故障原因人工反饋

2.3節(jié)只計算分析了指標(biāo)占比，不分析故障根因，由運(yùn)維人員根據(jù)異常指標(biāo)分析出故障根因后進(jìn)行根因反饋（用于后續(xù)機(jī)器學(xué)習(xí)）。

運(yùn)維人員在頁面提交的故障根因存入ES集群，作為機(jī)器學(xué)習(xí)的數(shù)據(jù)源。提交的具體內(nèi)容項包括：故障位置（精確到具體IP）、故障原因、故障現(xiàn)象等。由于機(jī)器智能分析[11,12]的功能還未開發(fā)，本文也會持續(xù)跟蹤相關(guān)功能的開發(fā)與使用。

3 應(yīng)用成效及分析

本文設(shè)計的CDN全鏈路分析系統(tǒng)已經(jīng)部署在中國移動CDN網(wǎng)絡(luò)中使用，流量高峰期支撐約3萬QPS的數(shù)據(jù)量，一個月時間跨度的日志檢索響應(yīng)時間大約600 ms。運(yùn)維人員針對“用戶請求延時”故障的分析時間減少約40%，對“請求響應(yīng)超時”故障的分析時間減少約45%，同時故障處理的準(zhǔn)確性也有了很大提升，故障自動分析結(jié)果與實際情況基本吻合，CDN網(wǎng)絡(luò)用戶的體驗有了明顯改善。上述效果主要得益于ES高效的搜索機(jī)制，在大數(shù)據(jù)量下更能發(fā)揮出優(yōu)勢。

4 結(jié)論

本文針對CDN運(yùn)維人員人工排查故障低效的情況，設(shè)計了一套全鏈路日志分析系統(tǒng)。通過在CDN網(wǎng)絡(luò)的各個環(huán)節(jié)增加特殊的traceId字段追蹤每個用戶的請求，將CDN的分發(fā)、調(diào)度日志結(jié)合起來分析，對全網(wǎng)數(shù)據(jù)存儲并開發(fā)日志搜索接口，根據(jù)CDN運(yùn)維人員自定義的查詢條件自動生成用戶請求鏈路拓?fù)鋱D與故障分析結(jié)果，同時運(yùn)維人員可以在頁面人工提交故障分析結(jié)果，減輕了人工工作量。但實際應(yīng)用中發(fā)現(xiàn)，系統(tǒng)在流量高峰期時段偶發(fā)判斷失誤的情況，原因是在大流量期間，僅靠簡單的閾值判斷故障顯得比較單一，沒能夠深層次地挖掘用戶日志的各項指標(biāo)。在后續(xù)工作中，將引入自適應(yīng)閾值[13]與強(qiáng)化學(xué)習(xí)、反饋學(xué)習(xí)機(jī)制，利用大數(shù)據(jù)量智能分析鏈路各個環(huán)節(jié)的質(zhì)量，為CDN的分發(fā)與調(diào)度模塊提供決策依據(jù)。