一.日志采集兩大體系
1）Aplus.JS是Web端（基于瀏覽器）日志采集技術(shù)方案
2）UserTrack是APP端（無線客戶端）日志采集技術(shù)方案
1.1瀏覽器頁面日志采集
(1)頁面瀏覽日志采集,PV,UV.
(2)頁面交互日志采集
頁面日志采集思路：
在HTML文檔內(nèi)的適當位置增加一個日志采集節(jié)點肥哎，當瀏覽器解析到這個節(jié)點時睛蛛，將自動觸發(fā)一個特定的http請求到日志采集服務壹甥。
所以阿里的頁面日志采集流程如下：
1)客戶端日志采集驰后，一般由一小段被植入頁面HTML文檔內(nèi)的JSP腳本執(zhí)行翰蠢。
2)客戶端日志發(fā)送状原，采集腳本執(zhí)行時菩收，會向日志服務器發(fā)起一個日志請求拨齐，將采集的數(shù)據(jù)發(fā)送給日志服務器驰贷。
3)服務器端日志收集盛嘿。服務器接收后立馬回應瀏覽器，并將收集內(nèi)容放入緩沖區(qū)異步處理饱苟。
4)服務器端日志解析文檔孩擂。
2.2?頁面交互日志采集
“黃金令箭”
1）業(yè)務方在"黃金令箭"的元數(shù)據(jù)管理界面依次注冊需要采集交互日志的業(yè)務，具體的業(yè)務場景以及場景下的具體交互采集點箱熬，注冊后生成與之對應的交互日志采集代碼模板类垦。
2）業(yè)務方將交互日志采集代碼植入目標頁面，并將采集代碼與需要監(jiān)測的交互行為做綁定城须。
3）當用戶在頁面上產(chǎn)生指定行為時蚤认，采集代碼和正常的業(yè)務互動響應代碼一起被觸發(fā)和執(zhí)行。
4）采集代碼在采集動作完成后將對應的日志通過HTTP協(xié)議發(fā)送到日志服務器糕伐，日志服務器接收到日志后砰琢，對于保存在HTTP請求參數(shù)部分的自定義數(shù)據(jù),即用戶上傳的數(shù)據(jù)，原則上不做解析處理，只做簡單的轉(zhuǎn)儲陪汽。
2.3?頁面日志的服務器端清洗和預處理
（1）識別流量攻擊训唱，網(wǎng)絡爬蟲，流量作弊挚冤。
（2）數(shù)據(jù)缺項補正况增。
（3）無效數(shù)據(jù)剔除。
（4）日志隔離分發(fā)训挡。
2.4無線客戶端的日志采集
無線客戶端的日志采集采用采集SDK來完成澳骤，使用名為UserTrack的SDK來進行無線客戶端的日志采集。UT把時間分為幾類澜薄，常用包括頁面事件和控件點擊事件为肮。
2.5日志采集的挑戰(zhàn)
1.日志分流與定制處理
針對短時間的流量熱點爆發(fā)，使得日志服務器端采用集中統(tǒng)一的解析處理方案變得不可能肤京，要求在日志解析和處理過程中必須考慮業(yè)務分流颊艳，日志優(yōu)先級控制以及根據(jù)業(yè)務特定定制處理。
阿里PV日志的請求位置URL是隨著頁面所在業(yè)務類型的不同而變化的蟆沫。通過盡可能靠前地布置路由差異籽暇，就可以盡可能早地進行分流温治，降低日志處理過程中的分支判斷消耗饭庞，并作為后續(xù)的計算資源調(diào)配的前提，提高資源利用效率熬荆。
2.采集和計算一體化設計
對于PV日志的問題（大規(guī)模URL正則）采用用戶可直觀感知的SPM規(guī)范和SPM元數(shù)據(jù)中心舟山。
3.大促銷保障
整個鏈路從端上埋點采集->日志服務器的收集->數(shù)據(jù)傳輸->日志實時解析->實時分析.
整個鏈路需要考慮服務器的收集能力（如峰值qps），數(shù)據(jù)傳輸能力卤恳，實時解析的吞吐量累盗，實時業(yè)務的分析能力。
所以首先?我們要實現(xiàn)服務器端推送配置到客戶端突琳，且做到高到達率若债；其次對日志進行分流，結(jié)合日志的重要程序及各類日志的大小拆融，實現(xiàn)了日志服務器端的拆分蠢琳，在實時處理上也要做優(yōu)化提高吞吐量。結(jié)合實時處理能力镜豹，評估峰值數(shù)據(jù)量傲须，在高峰期通過服務器端推送配置的方式對非重要日志進行適當?shù)南蘖鳎e峰后逐步恢復趟脂，還可以采用延時上報泰讽，部分采樣。
