2.1瀏覽器頁(yè)面日志采集

頁(yè)面瀏覽日志采集，該日志采集是PV年枕、UV指標(biāo)計(jì)算的基礎(chǔ)标捺，也具有一定的挑戰(zhàn)性懊纳。

頁(yè)面瀏覽日志采集是在頁(yè)面發(fā)送完HTTP請(qǐng)求后，得到服務(wù)器響應(yīng)亡容，并開始在頁(yè)面進(jìn)行渲染后才開始的嗤疯。也就是在HTTP中某一個(gè)節(jié)點(diǎn)增加一個(gè)日志采集節(jié)點(diǎn)，當(dāng)瀏覽器解析到該節(jié)點(diǎn)時(shí)闺兢，就向服務(wù)器發(fā)起日志采集請(qǐng)求茂缚。

日志采集的幾個(gè)重要步驟：

1.瀏覽器日志采集

主要采集當(dāng)前頁(yè)面參數(shù)戏罢，瀏覽行為上下午信息，運(yùn)行環(huán)境

2.瀏覽器日志發(fā)送

可能采集完后立即發(fā)送脚囊，也可能延遲發(fā)送龟糕，因?yàn)槿绻麛?shù)據(jù)量較大，會(huì)采取合并多條日志再發(fā)送的策略悔耘。減少IO次數(shù)讲岁，

3.日志采集服務(wù)器接收日志

服務(wù)器收到日志后會(huì)立馬返回瀏覽器一個(gè)成功響應(yīng)，以避免瀏覽器的渲染的延遲衬以。接收到的日志會(huì)進(jìn)入日志緩沖區(qū)缓艳。

4.日志采集服務(wù)器解析并存檔日志

主要是轉(zhuǎn)義和解碼

頁(yè)面交互日志采集，用戶喜好看峻、系統(tǒng)優(yōu)化點(diǎn)等業(yè)務(wù)都是基于此日志來(lái)完成的阶淘。

交互日志相較于頁(yè)面瀏覽日志，更多樣化互妓，無(wú)法規(guī)定其統(tǒng)一的采集內(nèi)容溪窒。需要技術(shù)人員更多的參與到其中，個(gè)性化程度較高车猬。

阿里內(nèi)部通過(guò)注冊(cè)要采集的交互日志業(yè)務(wù)霉猛，具體的業(yè)務(wù)場(chǎng)景以及具體交互采集點(diǎn)來(lái)自動(dòng)生成采集日志的代碼模版。

也就是指定要采集的交互行為珠闰。

行為日志可與瀏覽日志做關(guān)聯(lián)運(yùn)算。

日志的服務(wù)器端清洗和預(yù)處理

對(duì)于實(shí)時(shí)性要求不高的應(yīng)用場(chǎng)合瘫辩，需要對(duì)日志做清洗和預(yù)處理伏嗜。

1.識(shí)別流量攻擊、流量作弊伐厌、網(wǎng)絡(luò)爬蟲

流量攻擊指段時(shí)間內(nèi)多次發(fā)起訪問(wèn)承绸，按照一定的規(guī)則解析出流量攻擊后要馬上將數(shù)據(jù)反補(bǔ)回業(yè)務(wù)系統(tǒng)進(jìn)行指定IP的防御

流量作弊多現(xiàn)與廣告點(diǎn)擊等業(yè)務(wù)場(chǎng)景，識(shí)別出來(lái)減少成本及損失

網(wǎng)絡(luò)爬蟲需要指定一定的反爬機(jī)制

2.數(shù)據(jù)補(bǔ)正

如用戶登陸后挣轨，對(duì)稍早一些的該用戶日志信息作填充军熏。方便下游統(tǒng)計(jì)和方便計(jì)算。

3.無(wú)效數(shù)據(jù)剔除卷扮。

由于業(yè)務(wù)變更荡澎，頁(yè)面端的日志采集配置沒(méi)有發(fā)生相應(yīng)的變更，產(chǎn)生了一些垃圾日志晤锹。會(huì)占用存儲(chǔ)摩幔，也會(huì)影響下游的計(jì)算效率和準(zhǔn)確性，固剔除這部分?jǐn)?shù)據(jù)鞭铆。

4.數(shù)據(jù)隔離分發(fā)

出于安全性考慮或者業(yè)務(wù)特征的考慮或衡，在某些日志進(jìn)入公共數(shù)據(jù)環(huán)境之前需要做日志隔離。

2.2無(wú)線客戶端日志采集

會(huì)對(duì)日志做分類，分為頁(yè)面事件和控件點(diǎn)擊事件封断，而控件點(diǎn)擊事件又分為多種斯辰，如單擊、雙擊坡疼、滑動(dòng)彬呻、長(zhǎng)按等，下游的分析可能只針對(duì)某一類事件回梧，而不用拿全部的事件日志废岂。固將事件分類可以有效提升下游的分析，也有利于結(jié)構(gòu)化存儲(chǔ)狱意。

1.頁(yè)面日志一般會(huì)在用戶退出該頁(yè)面時(shí)發(fā)送日志湖苞，因?yàn)檫@樣可以記錄下用戶停留在此頁(yè)面的時(shí)長(zhǎng)。也可以減少日志量详囤，因?yàn)槿绻M(jìn)入頁(yè)面發(fā)送一條日志财骨，離開時(shí)發(fā)送一條日志，則發(fā)送了兩條日志藏姐。如果只是在離開時(shí)發(fā)送日志隆箩，則只發(fā)送了1條。在頁(yè)面日志中可以故意多收集一些信息羔杨，如上個(gè)頁(yè)面的信息甚至是上上個(gè)頁(yè)面的信息捌臊。這樣就可以分析當(dāng)前頁(yè)面的來(lái)源搜索關(guān)鍵字等。

2.除了頁(yè)面瀏覽日志外還有頁(yè)面點(diǎn)擊日志和其他日志兜材。

頁(yè)面點(diǎn)擊日志就是常見(jiàn)的用戶點(diǎn)擊操作理澎，其他日志就是用戶自定義的一些列操作日志。

除了上訴日志曙寡，還可以記錄應(yīng)用崩潰的日志糠爬，應(yīng)用退出的日志，應(yīng)用切換的日志等举庶。這些日志對(duì)改進(jìn)應(yīng)用自身有很大的幫組执隧。

設(shè)備標(biāo)識(shí)難以采集問(wèn)題：

web網(wǎng)頁(yè)端如果采集不到設(shè)備信息，可以用cookie作為用戶標(biāo)識(shí)户侥，app端沒(méi)有cookie镀琉。阿里的做法是用算法對(duì)每一臺(tái)app設(shè)備生成一個(gè)UTDID，隨著各個(gè)品牌手機(jī)權(quán)限的收攏添祸，目前該UTDID還不是很完善滚粟。

無(wú)線客戶端的日志上傳遵循一些列策略，不是來(lái)一條日志上傳一條刃泌，有積贊的日志大小凡壤、積贊日志時(shí)長(zhǎng)署尤、app的切換、長(zhǎng)時(shí)間停留無(wú)操作等都是上傳契機(jī)亚侠。

2.3日志采集的挑戰(zhàn)

總結(jié)起來(lái)就是在面對(duì)海量日志的情況下如何高度結(jié)構(gòu)化曹体、規(guī)范化的組織日志。以及高速硝烂、不重不漏的傳輸日志箕别。

為解決上訴問(wèn)題，阿里巴巴采用如下2個(gè)解決方案：

1.日志分流和定制處理

日志分流是指頁(yè)面在對(duì)日志服務(wù)器發(fā)起日志傳送請(qǐng)求時(shí)的分流滞谢，可以根據(jù)業(yè)務(wù)的類型而改變請(qǐng)求的URL串稀，分別將請(qǐng)求打到不同的服務(wù)，以達(dá)到分流狮杨、分開熱點(diǎn)日志和定常日志母截，讓熱點(diǎn)日志不要干擾定常日志的需求。

2.采集與計(jì)算一體化處理

大促保障

端上埋點(diǎn)采集-日志服務(wù)器收集-數(shù)據(jù)傳輸-實(shí)時(shí)分析橄教。在這4個(gè)環(huán)境中清寇，某一個(gè)環(huán)境出了問(wèn)題，這條日志處理鏈路都是失敗的护蝶，要保證日志鏈路就是要保證以上4個(gè)流程的高效华烟、無(wú)誤。

客戶端到日志服務(wù)器收集端：

阿里采用了日志服務(wù)器推送配置到客戶端形成相應(yīng)的日志采集策略持灰。并且在客戶端日志URL到日志服務(wù)器端做了日志到達(dá)分流處理盔夜，將不同業(yè)務(wù)類型的日志做分流處理。

結(jié)合實(shí)時(shí)處理端的處理能力堤魁，評(píng)估峰值數(shù)據(jù)量比吭。在高峰期采用服務(wù)端推送配置到客戶端來(lái)達(dá)到對(duì)不重要的日志進(jìn)行限流，以達(dá)到暫時(shí)削峰的作用姨涡。錯(cuò)峰后又逐步將延遲推送的日志上傳到日志服務(wù)器。延遲的策略有延遲上報(bào)吧慢、部分采樣等涛漂。所謂延遲上傳，即先把日志保存在客戶端检诗，待配置恢復(fù)后再上傳到服務(wù)器匈仗。部分采用是針對(duì)特殊的場(chǎng)景，如對(duì)app的性能監(jiān)控逢慌，內(nèi)存消耗等日志悠轩，只選取小部分日志上傳，因?yàn)樾〔糠秩罩揪途哂写硇粤斯テ谩０⒗锷踔磷隽酥苯釉谌罩静杉?wù)器端調(diào)用API做計(jì)算火架。減少日志傳輸流程鉴象，減少出錯(cuò)和資源占用。