網站統計中的資料收集原理及實現(openResty篇）
引言:
網站資料統計分析工具是網站站長和運營人員經常使用的一種工具，比較常用的有谷歌分析、百度統計和騰訊分析等等。所有這些統計分析工具的第一步都是網站訪問資料的收集。目前主流的資料收集方式基本都是基於javascript的。本文將簡要分析這種資料收集的原理，並一步一步實際搭建一個實際的資料收集系統。
1.資料收集原理分析
簡單來說，網站統計分析工具需要收集到使用者瀏覽目標網站的行為（如開啟某網頁、點選某按鈕、將商品加入購物車等）及行為附加資料（如某下單行為產生的訂單金額等）。早期的網站統計往往只收集一種使用者行為：頁面的開啟。而後使用者在頁面中的行為均無法收集。這種收集策略能滿足基本的流量分析、來源分析、內容分析及訪客屬性等常用分析視角，但是，隨著ajax技術的廣泛使用及電子商務網站對於電子商務目標的統計分析的需求越來越強烈，這種傳統的收集策略已經顯得力不能及。
後來，Google在其產品谷歌分析中創新性的引入了可定製的資料收集指令碼，使用者通過谷歌分析定義好的可擴充套件介面，只需編寫少量的javascript程式碼就可以實現自定義事件和自定義指標的跟蹤和分析。目前百度統計、搜狗分析等產品均照搬了谷歌分析的模式。
其實說起來兩種資料收集模式的基本原理和流程是一致的，只是後一種通過javascript收集到了更多的資訊。下面看一下現在各種網站統計工具的資料收集基本原理。
2.流程概覽
首先通過一幅圖總體看一下資料收集的基本流程。
首先，使用者的行為會觸發瀏覽器對被統計頁面的一個http請求，這裡姑且先認為行為就是開啟網頁。當網頁被開啟，頁面中的埋點javascript片段會被執行，用過相關工具的朋友應該知道，一般網站統計工具都會要求使用者在網頁中加入一小段javascript程式碼，這個程式碼片段一般會動態建立一個script標籤，並將src指向一個單獨的js檔案，此時這個單獨的js檔案（圖1中綠色節點）會被瀏覽器請求到並執行，這個js往往就是真正的資料收集指令碼。資料收集完成後，js會請求一個後端的資料收集指令碼（圖1中的backend），這個指令碼一般是一個偽裝成圖片的動態指令碼程式，可能由php、python或其它服務端語言編寫，js會將收集到的資料通過http引數的方式傳遞給後端指令碼，後端指令碼解析引數並按固定格式記錄到訪問日誌，同時可能會在http響應中給客戶端種植一些用於追蹤的cookie。
上面是一個數據收集的大概流程，下面以谷歌分析為例，對每一個階段進行一個相對詳細的分析。
2.1埋點指令碼執行階段
若要使用谷歌分析（以下簡稱GA），需要在頁面中插入一段它提供的javascript片段，這個片段往往被稱為埋點程式碼。下面是我的部落格中所放置的谷歌分析埋點程式碼截圖：
其中_gaq是GA的的全域性陣列，用於放置各種配置，其中每一條配置的格式為：
_gaq.push(['Action', 'param1', 'param2', ...]);Action指定配置動作，後面是相關的引數列表。GA給的預設埋點程式碼會給出兩條預置配置，_setAccount用於設定網站標識ID，這個標識ID是在註冊GA時分配的。_trackPageview告訴GA跟蹤一次頁面訪問。更多配置請參考：
就本文來說，_gaq的機制不是重點，重點是後面匿名函式的程式碼，這才是埋點程式碼真正要做的。這段程式碼的主要目的就是引入一個外部的js檔案（ga.js），方式是通過document.createElement方法建立一個script並根據協議（http或https）將src指向對應的ga.js，最後將這個element插入頁面的dom樹上。
注意ga.async = true的意思是非同步呼叫外部js檔案，即不阻塞瀏覽器的解析，待外部js下載完成後非同步執行。這個屬性是HTML5新引入的。
3.資料收集指令碼執行階段
資料收集指令碼（ga.js）被請求後會被執行，這個指令碼一般要做如下幾件事：
(1)、通過瀏覽器內建javascript物件收集資訊，如頁面title（通過document.title）、referrer（上一跳url，通過document.referrer）、使用者顯示器解析度（通過windows.screen）、cookie資訊（通過document.cookie）等等一些資訊。
(2)、解析_gaq收集配置資訊。這裡面可能會包括使用者自定義的事件跟蹤、業務資料（如電子商務網站的商品編號等）等。
(3)、將上面兩步收集的資料按預定義格式解析並拼接。
(4)、請求一個後端指令碼，將資訊放在http request引數中攜帶給後端指令碼。
這裡唯一的問題是步驟(4)，javascript請求後端指令碼常用的方法是ajax，但是ajax是不能跨域請求的。這裡ga.js在被統計網站的域內執行，而後端指令碼在另外的域（GA的後端統計指令碼是http://www.google-analytics.com/__utm.gif），ajax行不通。一種通用的方法是js指令碼建立一個Image物件，將Image物件的src屬性指向後端指令碼並攜帶引數，此時即實現了跨域請求後端。這也是後端指令碼為什麼通常偽裝成gif檔案的原因。通過http抓包可以看到ga.js對__utm.gif的請求：
可以看到ga.js在請求__utm.gif時帶了很多資訊，例如utmsr=1280×1024是螢幕解析度，utmac=UA-35712773-1是_gaq中解析出的我的GA標識ID等等。
值得注意的是，__utm.gif未必只會在埋點程式碼執行時被請求，如果用_trackEvent配置了事件跟蹤，則在事件發生時也會請求這個指令碼。
由於ga.js經過了壓縮和混淆，可讀性很差，我們就不分析了，具體後面實現階段我會實現一個功能類似的指令碼。
4.後端指令碼執行階段
GA的__utm.gif是一個偽裝成gif的指令碼。這種後端指令碼一般要完成以下幾件事情：
1、解析http請求引數的到資訊。
2、從伺服器（WebServer）中獲取一些客戶端無法獲取的資訊，如訪客ip等。
3、將資訊按格式寫入log。
5、生成一副1×1的空gif圖片作為響應內容並將響應頭的Content-type設為image/gif。
5、在響應頭中通過Set-cookie設定一些需要的cookie資訊。
之所以要設定cookie是因為如果要跟蹤唯一訪客，通常做法是如果在請求時發現客戶端沒有指定的跟蹤cookie，則根據規則生成一個全域性唯一的cookie並種植給使用者，否則Set-cookie中放置獲取到的跟蹤cookie以保持同一使用者cookie不變（見下圖）。
這種做法雖然不是完美的（例如使用者清掉cookie或更換瀏覽器會被認為是兩個使用者），但是是目前被廣泛使用的手段。注意，如果沒有跨站跟蹤同一使用者的需求，可以通過js將cookie種植在被統計站點的域下（GA是這麼做的），如果要全網統一定位，則通過後端指令碼種植在服務端域下（我們待會的實現會這麼做）。
5.系統的設計實現
[注]:這裡的例子 是leo-zeng 自己線下完成的一個demo；
根據上述原理，我自己搭建了一個訪問日誌收集系統。總體來說，搭建這個系統要做如下的事：
下面詳述每一步的實現。我將這個系統叫做XX官網日誌收集CLT的一個前期demo (XX 是我當前的公司）。
確定收集的資訊
為了簡單起見，我不打算實現GA的完整資料收集模型，而是收集以下資訊。
5.1埋點程式碼
埋點程式碼我將借鑑GA的模式，但是目前不會將配置物件作為一個FIFO佇列用。一個埋點程式碼的模板如下：
var _maq = _maq || [];
_maq.push(['_setAccount', '網站標識']);
(function() {
var ma = document.createElement('script'); ma.type = 'text/javascript'; ma.async = true;
ma.src = ('https:' == document.location.protocol ? 'https://192.168.1.128' : 'http:/192.168.1.128') + ':8009/ma.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ma, s);
})();我這裡nginx 中配置的域名是192.168.1.128 ；統計指令碼的名稱為ma.js。當然這裡有一點小問題，因為我並沒有https的伺服器，所以如果一個https站點部署了程式碼會有問題，不過這裡我們先忽略吧。
5.2 前端統計指令碼
一個統計的js 指令碼：
(function () {
var params = {};
//Document物件資料
if(document) {
params.domain = document.domain || '';
params.url = document.URL || '';
params.title = document.title || '';
params.referrer = document.referrer || '';
}
//Window物件資料
if(window && window.screen) {
params.sh = window.screen.height || 0;
params.sw = window.screen.width || 0;
params.cd = window.screen.colorDepth || 0;
}
//navigator物件資料
if(navigator) {
params.lang = navigator.language || '';
}
//解析_maq配置
if(_maq) {
for(var i in _maq) {
switch(_maq[i][0]) {
case '_setAccount':
params.account = _maq[i][1];
break;
default:
break;
}
}
}
//拼接引數串
var args = '';
for(var i in params) {
if(args != '') {
args += '&';
}
args += i + '=' + encodeURIComponent(params[i]);
}
//通過Image物件請求後端指令碼
var img = new Image(1, 1);
img.src = 'http://192.168.1.128:8009/1.gif?' + args;
})();整個指令碼放在匿名函式裡，確保不會汙染全域性環境。功能在原理一節已經說明，不再贅述。其中1.gif是後端指令碼。
5.3日誌格式
5.3.1日誌採用每行一條記錄的方式，採用不可見字元^A^，具體格式如下：
時間^A^IP^A^域名^A^URL^A^頁面標題^A^Referrer^A^解析度高^A^解析度寬^A^顏色深度^A^語言^A^客戶端資訊^A^使用者標識^A^網站標識
5.4 後端指令碼
為了簡單和效率考慮，我打算直接使用nginx的access_log做日誌收集，不過有個問題就是nginx配置本身的邏輯表達能力有限，所以我選用了OpenResty做這個事情。OpenResty是一個基於Nginx擴展出的高效能應用開發平臺，內部集成了諸多有用的模組，其中的核心是通過ngx_lua模組集成了Lua，從而在nginx配置檔案中可以通過Lua來表述業務。關於openresty的網站可以看下 ：https://moonbingbing.gitbooks.io/openresty-best-practices/content/lua/build_env.html
首先要配置nginx.conf 中的配置（主要是要定義日誌格式）：
user nginx;
worker_processes 4;
pid /opt/logs/nginx/nginx.pid;
error_log /opt/logs/nginx/error.log;
events {
use epoll;
worker_connections 10240;
}
http {
include mime.types;
#default_type 'text/html';
#定義日誌格式
#default_type 'application/octet-stream';
#指定lua_mongol 初始化預設路徑
default_type 'text/plain';
lua_package_path '/opt/opentresty/lualib/?/init.lua;;';
charset utf-8;
error_log /opt/logs/nginx/error.log;
#關閉預設的日誌接收
access_log off;
#log_format main '$remote_addr\t$uid_got$uid_set\t$http_host\t$time_iso8601\t$request\t$status\t$body_bytes_sent\t$http_referer\t$request_time\t$http_user_agent';
log_format tick '$msec^A^ $remote_addr^A^ $u_domain^A^ $u_url^A^ $u_title^A^ $u_referrer^A^ $u_sh^A^ $u_sw^A^ $u_cd^A^ $u_lang^A^ $http_user_agent^A^ $u_utrace^A^ $u_account';
client_max_body_size 100m;
sendfile on;
keepalive_timeout 60;
fastcgi_intercept_errors on;
proxy_connect_timeout 60;
proxy_send_timeout 90;
proxy_read_timeout 1800;
large_client_header_buffers 4128k;
proxy_ignore_client_abort on;
gzip on;
gzip_min_length 10k;
gzip_buffers 416k;
gzip_comp_level 2;
gzip_types text/plain text/javascript application/javascript application/x-javascript text/css application/xml application/octet-stream;
gzip_vary on;
#userid
userid on;
userid_name UUID;
userid_path /;
userid_expires max;
include _ext.conf;
include apps/*.conf;
}接下來是要配置自己 location中的內容 （我這裡location 發到apps 檔案下中的logColl.conf中）：
server{
#監聽 8009 端i口
listen 8009;
#服務名稱
server_name 192.168.1.128;
location /1.gif {
#偽裝成 gif檔案
default_type image/gif;
access_log off;
access_by_lua "
--使用者跟蹤cookie名為__utrace
local uid =ngx.var.cookie__utrace
if not uid then
--如果沒有生成一個跟蹤cookie，演算法為md5（時間戳+ip+客戶端資訊）
uid = ngx.md5(ngx.now()..ngx.var.remote_addr..ngx.var.http_user_agent)
end
ngx.header['Set-Cookie']={'__utrace='..uid..';path=/'}
if ngx.var.arg_domain then
--通過subrequest 到 i-log 記錄日誌，講引數和使用者跟蹤cookie帶過去
ngx.location.capture('/i-log?'..ngx.var.args..'&utrace='..uid)
end
";
#此請求不快取
add_header Expires "Fri,01 Jan 1980 00:00:00 GMT";
add_header Pragma "no-cache";
add_header Cache-Control "no-cache,max-age=0,must-revalidate";
#返回一個1*1的空gif圖片
empty_gif;
}
location /i-log {
#內部location，不允許外部直接訪問
internal;
#設定變數，注意需要unescape
set_unescape_uri $u_domain $arg_domain;
set_unescape_uri $u_url $arg_url;
set_unescape_uri $u_title $arg_title;
set_unescape_uri $u_referrer $arg_referrer;
set_unescape_uri $u_sh $arg_sh;
set_unescape_uri $u_sw $arg_sw;
set_unescape_uri $u_cd $arg_cd;
set_unescape_uri $u_lang $arg_lang;
set_unescape_uri $u_utrace &arg_utrace;
set_unescape_uri $u_account $arg_account;
#開啟日誌記錄
log_subrequest on;
#記錄日誌到ma.log 格式為tick
access_log /opt/logs/nginx/ma.log tick;
#輸出空字串
echo '';
}
location ~ .*\.(jpeg|png|bmp|swf|css|js)$ {
#靜態檔案，
root /opt/data/static;
expires 30d;
}
}要完全解釋這段指令碼的每一個細節有點超出本文的範圍，而且用到了諸多第三方ngxin模組（全都包含在OpenResty中了），重點的地方我都用註釋標出來了，可以不用完全理解每一行的意義，只要大約知道這個配置完成了我們在原理一節提到的後端邏輯就可以了。
6.日誌輪轉
真正的日誌收集系統訪問日誌會非常多，時間一長檔案變得很大，而且日誌放在一個檔案不便於管理。所以通常要按時間段將日誌切分，例如每天或每小時切分一個日誌。我這裡為了效果明顯，每一小時切分一個日誌。我是通過crontab定時呼叫一個shell指令碼實現的，shell指令碼如下：
_prefix="/path/to/nginx"
time=`date +%Y%m%d%H`
mv ${_prefix}/logs/ma.log ${_prefix}/logs/ma/ma-${time}.log
kill -USR1 `cat ${_prefix}/logs/nginx.pid`這個指令碼將ma.log移動到指定資料夾並重命名為ma-{yyyymmddhh}.log，然後向nginx傳送USR1訊號令其重新開啟日誌檔案。
然後再/etc/crontab里加入一行：
59 * * * * root /path/to/directory/rotatelog.sh在每個小時的59分啟動這個指令碼進行日誌輪轉操作。
7.關於分析
通過上面的分析和開發可以大致理解一個網站統計的日誌收集系統是如何工作的。有了這些日誌，就可以進行後續的分析了。本文只注重日誌收集，所以不會寫太多關於分析的東西。
注意，原始日誌最好儘量多的保留資訊而不要做過多過濾和處理。例如上面的MyAnalytics保留了毫秒級時間戳而不是格式化後的時間，時間的格式化是後面的系統做的事而不是日誌收集系統的責任。後面的系統根據原始日誌可以分析出很多東西，例如通過IP庫可以定位訪問者的地域、user agent中可以得到訪問者的作業系統、瀏覽器等資訊，再結合複雜的分析模型，就可以做流量、來源、訪客、地域、路徑等分析了。當然，一般不會直接對原始日誌分析，而是會將其清洗格式化後轉存到其它地方，如MySQL或HBase中再做分析。
分析部分的工作有很多開源的基礎設施可以使用，例如實時分析可以使用Storm，而離線分析可以使用Hadoop。當然，在日誌比較小的情況下，也可以通過shell命令做一些簡單的分析，例如，下面三條命令可以分別得出我的部落格在今天上午8點到9點的訪問量（PV），訪客數（UV）和獨立IP數（IP）
其它好玩的東西朋友們可以慢慢挖掘。