阿里巴巴的日志采集體系方案包括兩大體系： Ap us.JS Web（基于瀏覽器）日志采集技術(shù)方案： UserTrack APP 端（無線客戶端
日志采集技術(shù)方案。
本章從瀏覽器的頁面日志采集、無線客戶端的日志采集以及我們遇到的日志采集挑戰(zhàn)三塊內(nèi)容來闡述間里巴巴的日志采集經(jīng)驗。

2.1 瀏覽器的頁面日志采集

瀏覽器的頁面型產(chǎn)品／服務(wù)的日志采集可分為如下兩大類。
( 1 ）頁面瀏覽（展現(xiàn)）日志采集。顧名思義，頁面瀏覽日志是指當一個頁面被瀏覽器加載呈現(xiàn)時采集的日志。此類日志是最基礎(chǔ)的互聯(lián)網(wǎng)日志， 也是目前所有互聯(lián)網(wǎng)產(chǎn)品的兩大基本指標：頁面瀏覽量（ PageView, PY ）和訪客數(shù)（ Unique Visitors, UV ）的統(tǒng)計基礎(chǔ)。頁面瀏覽日志是目前成熟度和完備度最高 ，同時也是最具挑戰(zhàn)性的日志來集任務(wù)，我們將重點講述 類日志 的采集。
(2 ）頁面交互日志采集。當頁面加載和渲染完成之后，用戶可以在頁面上執(zhí)行各類操作。隨著互聯(lián) 網(wǎng)前端技術(shù)的不斷發(fā)展，用戶可在瀏覽
器內(nèi)與網(wǎng)頁進行的互動已經(jīng)豐富到只有想不到?jīng)]有做不到的程度，互動設(shè)計都要求采集用戶的互動行為數(shù)據(jù) ，以便通過 化獲知用戶的興趣點或者體驗優(yōu)化點。交互日志采集就是為此類業(yè)務(wù)場景而生的。
除此之外 還有 些專門針對某些特定統(tǒng)計場合的日志采集需求，如專門采集特定媒體在頁面被曝光狀態(tài)的曝光日志、用戶在線狀態(tài)的實時監(jiān)測等，但在基本原理上都脫胎于上述兩大類。限于篇幅，此內(nèi)容在本書中就不予展開介紹了。

2.1.1 頁面瀏覽日志采集流程

網(wǎng)站頁面是互聯(lián)網(wǎng)服務(wù)的基本載體，即使在如今傳統(tǒng)互聯(lián)網(wǎng)形態(tài)逐漸讓位于移動互聯(lián)網(wǎng) 的背景下 HTML 頁面依舊是最普遍的業(yè)務(wù)形態(tài)，
對于以網(wǎng)頁為基本展現(xiàn)形式 互聯(lián)網(wǎng)產(chǎn)品和服務(wù)，衡量其業(yè)務(wù)水平的基本指標是網(wǎng)頁瀏覽量 PV ）和訪客數(shù)（ UV ）。為此，我們需要采集頁
面被瀏覽器加載展現(xiàn)的記錄，這是最原始的互聯(lián)網(wǎng)日志采集需求，也是切互聯(lián)網(wǎng)數(shù)據(jù)分析得以展開的基礎(chǔ)和前提。
目前典型的網(wǎng)頁訪問過程是以瀏覽器請求、服務(wù)器響應(yīng)并返回所請求的內(nèi)容 （大 多以 HTML 文檔的形式）這種模式進行的，瀏覽器和服
務(wù)器之間的通信普遍遵守 HTTP 協(xié)議（超文本傳輸協(xié)議，目前以 HTTP1.1 為主，逐漸向最新的 HTTP 2.0 過渡）。瀏覽器發(fā)起的請求被稱為HTTP 請求（ HTTP Request ），服務(wù)器的返回則被稱為 HTTP 響應(yīng)（ HTTPResponse）
我們以用戶訪問向?qū)毷醉摚?www.taobao.com ）為例， 次典型的頁面訪問過程描述如圖 2.1 示。

（1）用戶在瀏覽器內(nèi)點擊淘寶首頁鏈接（或在地址欄中輸人www.taobao.com 并回車）。
（2）瀏覽器向淘寶服務(wù)器發(fā)起 HTTP 請求。在本例子中，用戶可以看見的內(nèi)容只是顯示于瀏覽器地址欄內(nèi)的 http://www.taobao.com ，而瀏覽器在執(zhí)行時，會解析用戶請求并按照 HTTP 協(xié)議中約定的格式將其轉(zhuǎn)化為 HTTP 請求發(fā)送出去。
請求行（ HTTP Request Line ）。請求行內(nèi)有 個要素，分別是請求方法、所請求資源的 URL 以及 HTTP 協(xié)議版本號。在本例子中，這 個要素分別是 GET http: //www.taobao.com ／以及 HTTP1.1 ，對于我們所討論的話題，記住請求行內(nèi)最重要的信息是這個URL 就可以了。
請求報頭（ HTTP Message Header ）。請求報頭是瀏覽器在請求時向服務(wù)器提交的附加信息，請求報頭一般會附加很 容項（每
項內(nèi)容被稱為一個頭域（ Header Field ），在不引起混 的情況下，往往將 Header Field 簡稱為 Header 。需要注意的是，如果用戶
在本次頁面訪問之前已經(jīng)到訪過網(wǎng)站或者已經(jīng)登錄，則一般都會在請求頭中附加一個或多個被稱為 Cookie 的數(shù)據(jù)項，其中記錄
了用戶上一次訪問時的狀態(tài)或者身份信息，我們只需理解瀏覽器在發(fā)起請求時會帶上一個標明用戶身份的 Cookie 即可。
請求正文（ HTTP Message Body ）。這 部分是可選的， 般而言，HTTP 請求的正文都是 的，可以忽略。
（3）服務(wù)器接收并解析請求。服務(wù)器端的業(yè)務(wù)處理模塊按業(yè)務(wù)邏輯處理本次請求并按照 HTT 協(xié)議規(guī)定的格式，將處理結(jié)果以 HTTP響應(yīng)
形式發(fā)回瀏覽器。
HTTP 請求相對應(yīng)，一個標準的 HTTP 應(yīng)也由三部分構(gòu)成。
·狀態(tài)行。狀態(tài)行標識了服務(wù)器對于此次 HTTP 請求的處理結(jié)果狀態(tài)行內(nèi)的主要內(nèi)容是一個由三位數(shù)字構(gòu)成的狀態(tài)碼，我們最熟
知的兩個狀態(tài)碼分別是代表成功響應(yīng)的 200 (OK ）和代表所請求的資源在服務(wù)器端沒有被找到的 404 (Not Found ）。
響應(yīng)報頭。服務(wù)器在執(zhí)行響應(yīng)時，同樣可以附加 些數(shù)據(jù)項，這些數(shù)據(jù)項將在瀏覽器端被讀取和使用。事實上，在大多數(shù)頁面和應(yīng)用中，響應(yīng)報頭內(nèi)的內(nèi)容在確保頁面正確顯示和業(yè)務(wù)正常進行方面都發(fā)揮著至關(guān)重要的作用。其中最重要的一類 Header 即上面所提到的 Cookie ，瀏覽器所記錄的 Cookie ，其實是由服務(wù)器在響應(yīng)報頭內(nèi)指令瀏覽器記錄的。舉個例子 ，如果用 戶在頁面登錄，則服務(wù)器會在登錄請求的響應(yīng)報頭內(nèi)指示瀏覽器新增一個名為use rid Cookie 項， 其中記錄了登錄用戶的 id 。如 一來當用戶隨后再次訪問該網(wǎng)站時，瀏覽器將自動在請求報頭內(nèi)附加這個 Cookie ，服務(wù)器由此即可得知本次請求對應(yīng)的用戶到底是誰：如果服務(wù)器發(fā)現(xiàn)瀏覽器在請求時傳遞過來的 Cookie 有缺失、錯誤或者需要更新，則會在響應(yīng)報頭內(nèi)指令瀏覽器增加或更新對應(yīng)的 Cookie。
·響應(yīng)正文。和請求正文一樣，這一部分在協(xié)議中 也被定義為可選部分，但對于大多數(shù) HTTP 響應(yīng)而言，這一部分都是非空的，瀏覽器請求的文檔、圖片、腳本等，其實就是被包裝在正文內(nèi)返回瀏覽器的。在本例子中，服務(wù)器會將淘寶首頁對應(yīng)的 HTML檔封裝在正文內(nèi)。
（4）瀏覽器接收到服務(wù)器的響應(yīng)內(nèi)容，并將其按照文檔規(guī)范展現(xiàn)給用戶，從而完成一次請求。在本例子中，瀏覽器請求淘寶首頁，服務(wù)器
返回對應(yīng)的 HTML 文檔，瀏覽器即按照 HTML 文檔規(guī)范解析文檔并將整個頁面渲染在屏幕上。

上面描述了一次典型的網(wǎng)頁瀏覽過程，如果需要記錄這次瀏覽行為，則采集日志的動作必然是附加在上述四個步驟中的某 環(huán)節(jié)內(nèi)完成
的。那么采集日志的動作，需要在第四步，也就是瀏覽器開始解析文檔時才能進行（前三步尚不能確保用戶已確實打開頁面）。所以在第四步服務(wù)器響應(yīng)瀏覽器的 HTML 文檔內(nèi)的適當位置增加一個日志采集節(jié)點，當瀏覽器解析到這個節(jié)點時，將自動觸發(fā) 個特定的HTTP 請求到日志采集服務(wù)器。如此一來，當日志采集服務(wù)器接收到這個請求時，就可以確定瀏覽器已經(jīng)成功地接收和打開了頁面。這就是目前幾乎所有互聯(lián)網(wǎng)網(wǎng)站頁面瀏覽日志采集的基本原理，而業(yè)界的各網(wǎng)頁日志采集的解決方案只是在實施的細節(jié)、自動采集內(nèi)容的廣度以及部署的便利性上有所不同。

目前阿里巴巴采用的頁面瀏覽日志采集方案的流程框架如圖 2.2示。在圖 2.2 所示的頁面瀏覽日志采集過程中，所涉及的日志相關(guān)的幾個主要過程簡單介紹如下：

（1）客戶端日志采集。日志采集工作 般由 小段被植人頁面HTML 文檔內(nèi)的 JavaSc ript 腳本來執(zhí)行。采集腳本被瀏覽器加載解析后執(zhí)行，在執(zhí)行時采集當前頁面參數(shù)、瀏覽行為的上下文信息（如讀取用戶訪問當前頁面時的上 步頁面）以及 些運行環(huán)境信息（如當前的瀏覽器和分辨率等）。
（2）客戶端日志發(fā)送。采集腳本執(zhí)行時，會向日志服務(wù)器發(fā)起一個日志請求，以將采集到的數(shù)據(jù)發(fā)送到日志服務(wù)器。日志采集和發(fā)送模塊 般會集成在同一個JavaScript 腳本文件內(nèi)，且通過互聯(lián)網(wǎng)瀏覽器必然支持的 HTTP 協(xié)議與日志服務(wù)器通信，采集到的日志信息 般以 URL 參數(shù)形式放在 HTTP日志請求的請求行內(nèi)。
（3）服務(wù)器端日志收集。日志服務(wù)器接收到客戶端發(fā)來的日志請求后，一般會立即向瀏覽器發(fā)回一個請求成功的響應(yīng)，以免對頁面的正常加載造成影響；同時，日志服務(wù)器的日志收集模塊會將日志請求內(nèi)容寫入一個日志緩沖區(qū)內(nèi)，完成此條瀏覽日志的收集。
（4）服務(wù)器端日志解析存檔。服務(wù)器接收到的瀏覽日志進人緩沖區(qū)后，會被一段專門的日志處理程序順序讀出并按照約定的日志處理邏輯
解析。由日志采集腳本記錄在日志請求行內(nèi)的參數(shù)，將在這個環(huán)節(jié)被解析（有時候伴隨著轉(zhuǎn)義和解碼）出來，轉(zhuǎn)存入標準的日志文件中并注人實時消息通道內(nèi)供其他后端程序讀取和進 步加工處理。

2.1.2 頁面交互日志采集流程

因為終端類型 頁面內(nèi)容、交互方式和用戶實際行為的千變?nèi)f化不可預(yù)估，交互日志的采集和 日志的采集不同，無法規(guī)定統(tǒng) 的采集內(nèi)容，呈現(xiàn)出高度自定義的業(yè)務(wù)特征。與之相適應(yīng)，在阿里巴巴的日志采集實踐中，交互日志的采集（即“黃金令箭”）是以技術(shù)服務(wù)的形式呈現(xiàn)的。
具體而言，“黃金令箭”是一個開放的基于 HTT 協(xié)議的日志服務(wù)，需要采集交互日志的業(yè)務(wù)（下文簡稱“業(yè)務(wù)方”），經(jīng)過如下步驟即可將自助采集的交互日志發(fā)送到日志服務(wù)器。
（1）業(yè)務(wù)方在“黃金令箭”的元數(shù)據(jù)管理界面依次注冊需要采集交互日志的業(yè)務(wù)、具體的業(yè)務(wù)場景以及場景下的具體交互采集點，在注冊完成之后，系統(tǒng)將生成與之對應(yīng)的交互日志來集代碼模板。
（2）業(yè)務(wù)方將交互日志采集代碼植入目標頁面，并將采集代碼與需要監(jiān)測的交互行為做綁定。
（3）當用戶在頁面上產(chǎn)生指定行為時，采集代碼和正常的業(yè)務(wù)互動響應(yīng)代碼 起被觸發(fā)和執(zhí)行。
（4）采 代碼在采集動作完成后將對應(yīng)的日志通過 HTTP 協(xié)議發(fā)送到日志服務(wù)器，日志服務(wù)器接收到日志后，對于保存在 HTTP 請求參數(shù)
部分的自定義數(shù)據(jù)，即用戶上傳的數(shù)據(jù)，原則上不做解析處理，只做簡單的轉(zhuǎn)儲。

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

上面介紹了阿里巴巴的兩類瀏覽器頁面日志的采集方案，并粗略介紹了日志到達日志服務(wù)器之后的解析處理。但在大部分場合下，經(jīng)過上
述解析處理之后的日志并不直接提供給下游使用。基于如下幾個原因，在對時效要求較寬松的應(yīng)用場合下，一般還需要進行相應(yīng)的離線預(yù)處理。
（1）識別流量攻擊、網(wǎng)絡(luò)爬蟲和流量作弊（虛假流量）。頁面日志是互聯(lián)網(wǎng)分析和大數(shù)據(jù)應(yīng)用的基礎(chǔ)源數(shù)據(jù)，在實際應(yīng)用中，往往存在占一定比例的虛假或者惡意流量日志，導(dǎo)致日志相關(guān)指標的統(tǒng)計發(fā)生偏差或明顯謬誤。為此，需要對所采集的日志進行合法性校驗，依托算法識別非正常的流量并歸納出對應(yīng)的過濾規(guī)則集加以濾除。這是 個長期而艱苦的對抗過程。
（2）數(shù)據(jù)缺項補正。為了便利后續(xù)的日志應(yīng)用和保證基本的數(shù)據(jù)統(tǒng)計口徑一致，在大多數(shù)情況下，需要對日志中的一些公用且重要的數(shù)據(jù)項做取值歸一 、標準化處理或反向補正。反向補正，即根據(jù)新日志對稍早收集的日志中的個別數(shù)據(jù)項做回補或修訂（例如，在用戶登錄后，對登錄前頁面日志做身份信息的回補）。
（3）無效數(shù)據(jù)剔除。在某些情況下，因業(yè)務(wù)變更或配置不當，在采集到的日志中會存在一些無意義、已經(jīng)失效或者冗余的數(shù)據(jù)項。這些數(shù)
據(jù)項不僅消耗存儲空間和運算能力，而且在偶然的情況下還可能干擾正常計算的進行。為了避免此類異常的發(fā)生，需要定時檢查配置并依照配置將此類數(shù)據(jù)項剔除。
（4）日志隔離分發(fā)?；跀?shù)據(jù)安全或者業(yè)務(wù)特性的考慮，某些日志在進入公共數(shù)據(jù)環(huán)境之前需要做隔離。
原始日志經(jīng)過上述的清洗、修正，并結(jié)構(gòu)化變形處理之后， Web頁面日志的采集流程就算完成了。此時的日志已經(jīng)具備了結(jié)構(gòu)化或者半
結(jié)構(gòu)化的特征，可以方便地被關(guān)系型數(shù)據(jù)庫裝載和使用。

2.2 無線客戶端的日志采集

無線客戶端的日志采集采用采集 SDK 來完成，在阿里巴巴內(nèi)部，多使用名為 UserTrac 來進行無線客戶端的日志采集。無線客戶端的日志采集和瀏覽器的日志采集方式有所不同，移動端的日志采集根據(jù)不同的用戶行為分成不同的事件，“事件”為無線客戶端日志行為的最小單位基于常規(guī)的分析， serTrack (UT ）把事件分成了幾類，常用的包括頁面事件（同前述的頁面瀏覽）和控件點擊事件（同前述的頁面交互）等。

2.2.1 頁面事件

每條頁面事件日志記錄三類信息 ①設(shè)備及用戶的基本信息：②被訪問頁面的信息，這里主要是一些業(yè)務(wù)參數(shù)（如商品詳情頁的商品 ID 、所屬的店鋪等） ; ③訪問基本路徑（如頁面來源、來源的來源 ），用于還原用戶完整的訪問行為。
對于頁面事件，不同的 有不同的實現(xiàn)，有些采集 SD 選擇在頁面創(chuàng)建時即發(fā)送日 志。結(jié)合業(yè)務(wù)分析， 提供了頁面事件的無痕埋點， 即無須開發(fā)者進行任何編碼即可實現(xiàn)。限于篇幅，本處主要講一下手動模式的埋點。 UT 提供了兩個接口，分別在頁面展現(xiàn)和頁面退出時調(diào)用。以進入手機淘寶的某店鋪詳情頁來舉例，當進入該店鋪詳情頁時，調(diào)用頁面展現(xiàn)的接口，該接口 記錄頁面進人時的 些狀態(tài)信息，但此時不發(fā)送日志；當從該店鋪詳情頁離開時（可能是在店鋪詳情頁上點擊某個商品到了對應(yīng)的商品詳情頁，也可能是退出了手機淘寶，抑或是點擊返 回，返回到了之前的一個頁面），調(diào)用頁面退出的接口，該接口會發(fā)送 日志 。除了基礎(chǔ)的兩個接口外，還提供了添加頁面擴展信息的接口；在頁面離開前，使用該接口提供的方法給頁面添加相關(guān) 數(shù)，比如給店鋪詳情頁添加店鋪 ID 、店鋪類別（天貓店鋪或淘寶店鋪） 等。
顯然 上述三個接口方法必須配合使用，即頁面展現(xiàn)和頁面退出方法必須成對使用，而頁面擴展信息的接口必須在使用頁面展現(xiàn)和頁面退
出方法的前 下使用。在頁面離開時發(fā)送日志，此時頁面停留時長就是天然自帶的準確值了。
上述三個方法是采集 SDK 提供的頁面事件采集的基礎(chǔ)方法 除此之外，為了平衡采集、計算和分析的成本，在部分場景下我們選擇采集更多的信息來減少計算及分析的成本。于是， UT 提供了透傳參數(shù)功能。所謂透傳參數(shù)，即把當前頁面的某些信息，傳遞到下一個頁面甚至下下一個頁面的日志中。在阿里系內(nèi)，使用 SPM (Super Position Model ，超級位置模型）進行來源去向的追蹤，在無線客戶端也同樣使用SPM, SPM 信息就可以通過透傳機制帶人到下一步甚至下下一步的瀏覽頁面，這樣整個用戶行為路徑還原就輕松實現(xiàn)了。

2.2.2 控件點擊及其他事件

和瀏覽器客戶端的日志采集一樣 ，交互日志的采集無法規(guī)定統(tǒng)一的采集內(nèi)容，交互類的行為呈現(xiàn)出高度自定義的業(yè)務(wù)特征。與之相適應(yīng)，在網(wǎng)里巴巴的無線客戶端日志采集實踐中，將交互日志采集從頁面事件采集中剝離出來，這就是控件點擊事件和其他事件。
先來說說控件點擊事件?？丶c擊事件比頁面事件要簡單得多，首先，它和頁面事件一樣，記錄了基本的設(shè)備信息、用戶信息：其次，它記錄了控件所在頁面名稱、控件名稱、控件的業(yè)務(wù)參數(shù)等。由于控件點擊事件的邏輯簡單得多，就是操作頁面上的某個控件，因此只需把相關(guān)
基礎(chǔ)信息告訴采集即可。
再來說說其他事件。所謂其他事件，就是用戶可以根據(jù)業(yè)務(wù)場景需求，使用自定義事件來采集相關(guān)信息。從某種程度上說，它幾乎能滿足用戶的所有需求，包括頁面事件和控件點擊事件，只是若采用通用的頁面事件埋點方法， 會幫助實現(xiàn)一些額外的功能（如上個頁面的信息）。
UT 提供了一個自定義埋點類，其包括：①事件名稱：②事件時長 ③事件所攜帶的屬性：④事件對應(yīng)的頁面。當然，具體實現(xiàn)什么功能，需要帶哪些內(nèi)容，各個采集 SDK 可以自行決定。
除了上述這些需要應(yīng)用開發(fā)者觸發(fā)的日志采集接口方法外，UT還提供了一些默認的日 志采集方法 ，比如可以自動捕獲應(yīng)用崩潰，并且產(chǎn)
生一條 日志記錄崩潰相關(guān)信息。類似的日志采集方法還有很多，比如應(yīng)用的退出 頁面的前后臺切換等。諸如 些和業(yè)務(wù)信息不是非常相關(guān)，
但又對分析起很大作用的日志采集 ，就完全沒有必要讓應(yīng)用開發(fā)者去觸發(fā)埋點了。

2.2.3 特殊場景

上述場景均為一個行為產(chǎn)生一條日志，如一次瀏覽、一次點擊等。如此用來處理普通的業(yè)務(wù)是足夠的，但對于阿里巴巴巨大的業(yè)務(wù)體量來說，為了平衡日志大小，減小流量消耗、采集服務(wù)器壓力、網(wǎng)絡(luò)傳輸壓力等，采集 SDK 提供了聚合功能，對某些場景如曝光或一些性能技術(shù)類日志 ，我們提倡在客戶端對這類日志進行適當聚合，以減少對日志采集服務(wù)器端的請求 ，適當減小日志大小?？傮w思路就是每個曝光的元素一般都屬于一個頁面，利用頁面的生命周期來實現(xiàn)適當?shù)木酆霞按_定發(fā)送時 。拿曝光日志來舉例，若 個商品的一次曝光就對應(yīng)一條日志的話，那么在搜索結(jié)果頁的一次滾屏瀏覽過程中將產(chǎn)生幾十條甚至上百條日志，從下游使用及分析的角度來說，其實只是想知道哪些內(nèi)容被曝光，此時為了平衡業(yè)務(wù)需求及減少全鏈路資源消耗，采集 SDK 提供了本地聚合功能，在客戶端對這類日志進行聚合，上傳聚合后的日志到采集服務(wù)器即可。同時對于一些只需要計數(shù)，而不需要知道具體內(nèi)容的場景，如需要分析某些接口的調(diào)用次數(shù)，此功能就更加凸顯出其作用了。
區(qū)別于瀏覽器的頁面訪問，在無線客戶端用戶的訪問行為路徑存在明顯的回退行為（如點擊回退按鈕、各種滑屏等），在進行業(yè)務(wù)分析時，
回退同樣作為特殊場景而存在。例如，“雙 11 ”主會場頁 女裝分會場→女裝店鋪 →回退到女裝分會場→女裝店鋪 ，在這個訪問路徑中，若只是按照普通的路徑來處理，則會認為第 次瀏覽的女裝分會場來源為店鋪 ，就會把女裝分會場的 次瀏覽效果記為女裝店鋪 帶來的倘若這樣處理，就會發(fā)現(xiàn)類似的活動承接頁其來源有 大部分均為各類詳情頁（店鋪詳情頁／商品詳情頁），這必然干擾到分析。所以針對這種場景，我們做了特殊的設(shè)計，利用頁面的生命周期，識別頁面的復(fù)用配合校的深度來識別是否是回退行為。
如上列舉了兩個比較典型的特殊場景，隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)的復(fù)雜性不斷提高，采集需要處理的特殊場景也層出不窮，限于篇幅，此處不再 一展開介紹。

2.2.4 H5 & Native 日志統(tǒng)一

簡單來說， APP 分為兩種： 種是純 Native APP; 種是既有 Native，又有 H5 頁面嵌入的 APP ，即 Hybrid APP 。當前，純 Native APP 經(jīng)非常少了，一般都是 Hybrid APP Native 頁面采用采集 SDK 進行日 志采集， H5 頁面 般采用基于瀏覽器的頁面日志采集方式進行采集。在當前的實踐中，由于采集方式的不同，采集到的內(nèi)容及采集服務(wù)器均分離開。若需要進行完整的數(shù)據(jù)分析，就需要將兩類日在數(shù)據(jù)處理時進行關(guān)聯(lián)。

要想實現(xiàn)Native HS 日 的統(tǒng) 處理，就需要對 Hybrid 日志有統(tǒng)一 方案。 的思路就是首先將兩類日志進行歸 。在阿 巴巴 團，分別考慮兩條路的優(yōu)缺點，考慮到兩種日志來集方式的特點以及關(guān)注點，我們選擇 Native 部署采集 SDK 的方式。
原因有二 一是采 SDK 可以采集到更 的設(shè)備相關(guān)數(shù)據(jù)，這在移動端的數(shù)據(jù)分析中尤為 要； 是采集 SDK 處理日志，會先在本地緩存，而后借機上傳，在網(wǎng)絡(luò)狀況不佳時延遲上報，保證數(shù)據(jù)不丟失。基于這兩點，我們選擇將 HS 日志歸到 Native 日志。
具體流程如下：
( 1) HS 頁面瀏覽和頁面交互的數(shù)據(jù)，在執(zhí)行時通過加載日志采集的JavaScript 腳本，采集當前頁面參數(shù)，包括瀏覽行為的上下文信息以及一 行環(huán)境信息。在 APP 中打開 HS 頁面和在瀏覽器中的處理完全一樣 ，在前端 面的開發(fā)中無須做任何特殊的處理，只需在頁面開發(fā)時手動植入日 JavaScript 腳本即可。
(2 ）在瀏覽器日 JavaScript 腳本中實現(xiàn)將所采 的數(shù)據(jù)打包到一個對象中，然后調(diào)用 WebView 框架的 JSBridge 接口，調(diào)用移動
客戶端對應(yīng)的接口方法，將埋點數(shù)據(jù)對象當作參數(shù)傳人。
(3 ）移動客戶端日志采集 SDK ，封裝提供接口，實現(xiàn)將傳人的內(nèi)容轉(zhuǎn)換成移動客戶端日志格式。采集 SDK 會根據(jù)日志類別來識別是頁面瀏覽事件，還是控件點擊事件，然后調(diào)用內(nèi)部相應(yīng)的接口進行處理，將埋點數(shù)據(jù)轉(zhuǎn)換成移動客戶端日志的統(tǒng)一格式。而后就同移動客戶端的日志處理一樣，先記錄到本地日志緩存中，擇機上傳。通過日志類別的識別來做不同的日志格式轉(zhuǎn)換，這樣，未來如果要實現(xiàn)新的事件類別，比如自定義事件，就不需要改動 WebView 層的接口，只 需改動 JavaScript的部分內(nèi)容及移動客戶端日志采集 SDK 中對應(yīng)的實現(xiàn)即可。
基于這種統(tǒng)一的方案，為后續(xù)構(gòu)建完整的用戶行為路徑還原樹打下了基礎(chǔ)。當然，此方案也有其局限性，必須要瀏覽器采集 JavaScript
Web View 、客戶端采集 SDK 的配合。而往往很多時候業(yè)務(wù)并不希望做任何調(diào)整，更多的是希望減少依賴。

2.2.5 設(shè)備標識

正如本章開頭所說的，所有互聯(lián)網(wǎng)產(chǎn)品的兩大基本指標是頁面瀏覽量（ Page View, PY ）和訪客數(shù)（ Unique Visitors, UV ）。 關(guān)于 UV于登錄用戶，可以使用用戶 ID 來進行唯 標識，但是很多日志行為并對不要求用戶登錄，這就導(dǎo)致在很多情況下采集上來的日志都沒有用戶ID PC 般使用 Cookie 信息來作為設(shè)備的唯一信息，對于 APP來說，我們就要想辦法獲取到能夠唯一標識設(shè)備的信息。隨著用戶的自我保護意識加強以及各系統(tǒng)升級，很多基本的設(shè)備信息獲取都不再那么容易。蘋果 UDID 禁用， IDFA IMEI IMSI了權(quán)限控制， Android 新系統(tǒng)也對設(shè)備信息的獲取做了權(quán)限控制。

2.2.6 日志傳輸

無線客戶端日志的上傳，不是產(chǎn)生一條日志上傳一條，而是無線客戶端產(chǎn)生 日志后，先存儲在客戶端本地，然后再伺機上傳。
客戶端數(shù)據(jù)上傳時是向服務(wù)器發(fā)送 POST 請求，服務(wù)器端處理上傳請求 ，對請求進行相關(guān)校驗 ，將數(shù)據(jù)追加到本地文件中進行存儲，存儲
方式使用 Nginx access_log, access_log 的切分維度為天，即當天接收的日志存儲到當天的日志文件中。考慮到后續(xù)的數(shù)據(jù)處理，以及特殊
時期不同日志的保障級別，還對日志進行了分流。對于重要的數(shù)據(jù)計算來說 ，很可能只需要頁面事件及控件點擊事件即可，此時就可以適當?shù)蒯尫牌渌愋腿罩镜馁Y源來處理更重要的頁面事件及控件點擊事件。
從客戶端用戶行為，到日志采集服務(wù)器的日志，整個日志采集的過程就算結(jié)束了。那么日志采集服務(wù)器的日志怎么給到下游呢？方法有很
多，阿里巴巴集團主要使用消息隊列（ TimeTunel, TT ）來實現(xiàn)從日志采集服務(wù)器到數(shù)據(jù)計算的 MaxCompute 。簡單來講，就是 TT 將消息收集功能部署到日志采集服務(wù)器上進行消息的收集，而后續(xù)的應(yīng)用可以是實時的應(yīng)用實時來訂閱 TT 收集到的消息，進行實時計算，也可以是離線的應(yīng)用定時來獲取消息，完成離線的計算。有關(guān)消息隊列，以及日志數(shù)據(jù)的統(tǒng)計計算等細節(jié)內(nèi)容，將在后續(xù)章節(jié)中進行詳細講述。

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

對于目前的互聯(lián)網(wǎng)行業(yè)而言，互聯(lián)網(wǎng)日志早已跨越初級的饑餓階段（大型互聯(lián)網(wǎng)企業(yè)的日均日志收集量均以億為單位計量），反而面臨海量日志的淹沒風險。各類采集方案提供者所面臨的主要挑戰(zhàn)已不是日志采集技術(shù)本身，而是如何實現(xiàn)日志數(shù)據(jù)的結(jié)構(gòu)化和規(guī)范化組織，實現(xiàn)更為高效的下游統(tǒng)計計算，提供符合業(yè)務(wù)特性的數(shù)據(jù)展現(xiàn)，以及為算法提供更便捷、靈活的支持等方面。

2.3.1 典型場景

1. 日志分流與定制處理

大型互聯(lián)網(wǎng)網(wǎng)站的日志類型和日志規(guī)模都呈現(xiàn)出高速增長的態(tài)勢，而且往往會出現(xiàn)短時間的流量熱點爆發(fā)。這一特點，使得在日志服務(wù)器
端采用集中統(tǒng)一的解析處理方案變得不可能，其要求在日志解析和處理過程中必須考慮業(yè)務(wù)分流（相互之間不應(yīng)存在明顯的影響，爆發(fā)熱點不應(yīng)干擾定常業(yè)務(wù)日志的處理）、日志優(yōu)先級控制，以及根據(jù)業(yè)務(wù)特點實現(xiàn)定制處理。例如，對于電商網(wǎng)站而言，數(shù)據(jù)分析人員對位于點擊流前端的促銷頁面和位于后端的商品頁面的關(guān)注點是不一樣的，而這兩類頁面的流量又往往同等重要且龐大 ，如果采用統(tǒng) 的解析處理方案，則往往需要在資源浪費（盡可能多地進行預(yù)處理）和需求覆蓋不全（僅對最重要的內(nèi)容進行預(yù)處理）兩個選擇之 間進行取舍。這種取舍的結(jié)果一般不是最優(yōu)的。
考慮到阿里日志體量的規(guī)模和復(fù)雜度，分治策略從一開始便是阿里互聯(lián)網(wǎng)日志采集體系的基本原則。這里以 PV 日志采集領(lǐng)域 個最淺顯
的例子來說明，與業(yè)界通用 的第三方 日志采集方案的日志請求路徑幾乎歸一不同，阿里 PV 日志的請求位置（ URL ）是隨著頁面所在業(yè)務(wù)類型的不同而變化的。通過盡可能靠前地布置路由差異，就可以盡可能早地進行分流，降低日志處理過程中 的分支判斷消耗，并作為后續(xù)的計算資源調(diào)配的前提，提高資源利用效率。與業(yè)界方案的普遍情況相比，阿里的客戶端日志采集代碼的一個突 出特點是實現(xiàn)了非常高的更新頻次（業(yè)界大多以季度乃至年為單位更新代碼，阿里則是以周／月為單位），并實現(xiàn)了更新的配置 。我們不僅考慮諸如日志分流處理之類的日志服務(wù)器端分布計算方案，而且將分類任務(wù)前置到客戶端（從某種程度上講，這才是真正的“分布式” ?。┮詫崿F(xiàn)整個系統(tǒng)的效能最大化。最后可以在計算后端幾乎無感知的情況下，承載更大的業(yè)務(wù)量并保證處理質(zhì)量和效率。

2.3.2 大促保障

日志數(shù)據(jù)在阿里系乃至整個電商系應(yīng)該都是體量最大的 類數(shù)據(jù)，在“雙 ”期間，日志必然會暴漲，近萬億的數(shù)據(jù)量對日志全鏈路來說，無疑是不小的挑戰(zhàn)（見圖 2.4 ）。

首先，端上實現(xiàn)了服務(wù)器端推送配置到客戶端，且做到高到達率；其次 ，對日志做了分流，結(jié)合日志的重要程度及各類日志的大小，實現(xiàn)了日志服務(wù)器端的拆分；最后，在實時處理方面，也做了不少的優(yōu)化以提高應(yīng)用的吞吐量。在上面幾項的基礎(chǔ)上，結(jié)合實時處理能力，評估峰
值數(shù)據(jù)量 ，在高峰期通過服務(wù)器端推送配置的方式對非重要日志進行適當限流 ，錯峰后逐步恢復(fù)。此處說的服務(wù)器端推送配置包含較多的內(nèi)容，首先是作用范圍，可以針對應(yīng)用、平臺、事件、事件中的某個場景：其次是具體實施，包括延遲上報、部分采樣等。所謂延遲上報，即配置生效后 ，滿足條件的日志將被暫時存在客戶端，待配置恢復(fù)后再上傳到服務(wù)器 ；所謂 采樣 ，即配置生效后，滿足條件的日志將被實施采樣（對于一些技術(shù)類日志，如頁面加載情況、消耗內(nèi)存等，可以實施采樣），只上報部分日志到服務(wù)器。讀到這里，可能會有讀者發(fā)現(xiàn)，整個日 志處理流程還是比較長的，對于對實時性要求極高的業(yè)務(wù)場景，如上鏈路顯然不能滿足需求。所以 方面，我們從業(yè)務(wù)上進行改造，采用端上記錄；另一方面，我們也在鏈路各環(huán)節(jié)做優(yōu)化，如從采集服務(wù)器直接完成解碼并調(diào)用業(yè)務(wù) 完成業(yè)務(wù)的計算（省去中間的傳輸和過 的處理） 。在這方面我們也面臨著巨大的挑戰(zhàn)，在保證穩(wěn)定的同時擴展功能， 在穩(wěn)定及業(yè)務(wù)深度之間做到很好的平衡。文章來源地址http://www.zghlxwxcb.cn/news/detail-824373.html

到了這里，關(guān)于大數(shù)據(jù)之路-日志采集（第二章）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！