【前言】
應朋友們的請求，我還是寫一篇關于服務器日志法進行網站分析的原理以及它的優毛病是什么。請朋友們注意，網站服務器日志法并不輕易進行，初學者，以及在盡大多數情況下，進行以用戶行動分析為核心的網站分析，用不到服務器日志法。不過，作為網站分析歷史不可分割的一部分以及重要的基礎篇章，服務器日志法仍然值得一書。下面的這篇文章也是我要撰寫的書中截取的內容（我要快馬加鞭快快寫了，已經辜負了太多朋友的重托，負疚負疚！）。
【正文】
網站分析收集數據的方法實在有五、六種之多，我們最常見的有三種，分辨是：服務器日志（Server Log）、頁面標記（Page Tag）和客戶端監測軟件收集（Client End/Desktop）。我的CWA博客（http://www.chinawebanalytics.cn）中重要講解的都是頁面標記法，今天則跟大家講解一下服務器日志方法的原理及優毛病。
1. 服務器日志是什么
真正意義上的網站分析是從服務器日志開端的，而且直到今天，分析服務器（也稱為server log file，或簡稱log file）日志仍然是網站分析的重要方法。
這里的服務器指的是網站服務器（Web Server），而服務器日志跟飛機的黑匣子一樣，是用來記錄網站服務器的運行信息的，或者簡略說，是用來記錄服務器中的什么頁面在什么時候被誰拜訪了。例如，假如你拜訪一次我的網站：http://www.chinawebanalytics.cn，那么一般情況下，網站服務器的日志就會記錄在某時某刻來自某個IP的拜訪者索引了網頁“/index.php”。當然，網站服務器日志還會記錄其他很多內容，這些內容能夠幫助我們分析網站的流量和拜訪者在網站上的行動。
下面這個圖闡明了網站日志是如何產生的。當用戶拜訪一個網站的時候，事實上是拜訪這個網站的某一個具體的頁面，我們假設這個頁面叫Page 1。這時，我們的這個拜訪行動會懇求服務器中Page 1的實際的文件，隨之把這個文件下載到瀏覽器上。由于懇求和下載行動都會引起服務器的響應和相應的舉動，因此就有必要記錄下服務器的這些舉動。
你會問，為什么需要記錄服務器的舉動呢？原因很簡略，由于我們不想讓這個服務器變成“哈爾9000”（哈爾9000是庫布里克《2001太空奧德賽》里面有了自我意識的電腦，它直接要挾到了電影中的宇航員）啊！這當然只是開玩笑，不過目標并無差別，就是能夠通過服務器日志，對服務器的運行歷史進行記錄，這樣當有任何異常情況產生的時候，我們都能夠通過日志探尋標題產生的原因——跟記錄飛機運行狀態的黑匣子的作用十分類似。
原理看起來并不復雜，不過log file實際上并不簡略。為了讓log file具有可讀性，log file并不可以按照各個網站所有者的愛好隨便記錄的，而是有自己的規范。W3C組織定義了server log file的通用格局（假如你有愛好，可以在這里看看這些格局都是如何定義的：http://www.w3.org/Daemon/User/Config/Logging.html#common_logfile_format），而其他一些組織或者個人又根據自己的需要額外擴大了這個格局，使log file能夠比擬全面地記錄網站服務器進行的各種運動。
一條尺度的web server log記錄通常包含如下信息：
l 遠程主機（Remote Host）的IP地址/名字
l 登錄名（Log Name）
l 登錄全名（Full Name）
l 懇求產生的日期（Date）
l 懇求產生的時間（Time）
l 和尺度格林威治時間的差值（GMT Offset）
l 懇求的方法（Request Method）
l 懇求的文件的地址（File）
l 懇求遵照的協議（Protocol）
l 懇求的狀態（Status）
l 被懇求文檔的長度（Length）
下面是一條尺度的log file記錄：
202.71.113.38 – - ［03/Jan/2010:01:56:12 +0800］ “GET /Chinawebanalytics/Sidney.htm HTTP/1.0” 200 5122
從左到右，202.71.113.38就是遠程主機的IP；而登錄名和登錄全名指的是發起這個懇求的用戶的名字，這個一般大家當然是不想要流露的了，所以遠程主機會禁止給出這兩個信息，log file當然就記錄不下來了，用兩個短中劃線代替。然后，03/Jan/2010是懇求產生的日期，01:56:12則是時間，之后的+0800是指比格林威治時間要晚8個小時，就是我們北京時間了。再之后的GET是懇求的方法，另一種方法是POST，可以簡略懂得為GET就是索取，POST就是提交。接著：/Chinawebanalytics/Sidney.htm是被懇求文件的地址，可以是盡對地址也可以是相對地址。HTTP/1.0是懇求所遵照的協議，這里的協議是HTTP 1.0。全部記錄的結尾是兩個數字，其中200表現一種懇求的狀態，意思是懇求一切正常。有時候這個數字會顯示為404，信任大家一看到這個數字就頭痛，它表現懇求的文件無法找到（file not found）；又有時候，這個數字會顯示為301，表現頁面被重新定向到了別的地址。最后的一個數字5593，表現所懇求的文檔的長度為5122 bytes。
通用格局實在很簡略，但是里面的這11類記錄往往不足夠幫助我們進行更深進的分析，因此其他的一些記錄被參加進來，其中最重要的一些是：
l 懇求起源（Referrer）：指連接到被懇求資源的網站的URL。假如懇求時通過點擊一個鏈接時產生，那么這個項目就會被記錄；
l 客戶端（User Agent）：記錄用戶的瀏覽器或者發出懇求的程序的相干信息；
l 所需時間（Time Taken）：從懇求的發出到懇求的資源全部傳輸完畢所需花費的時間；
l Cookie。
看起來，網站服務器日志所記錄的內容是很有限的，比起我們動輒上萬行的編程實在是九牛一毛。但是，千萬別認為網站服務器日志文件會很小，對于一些大網站，每分每秒都有很多拜訪者對網站服務器進行懇求，所以日志文件會積少成多，成為巨型的數據文件。有時候，一個小時的記錄就能超過數G。什么，你網站的服務器日志一個月才1M？要加油啊，沒有人氣的網站可沒有生命力。
講到這兒，該說說歷史了。網站分析就是從網站服務器日志開端的，或者更準確的說，網站服務器日志自出生之日起，就是為網站分析所用的。最早，人們可是把所有的記錄都拿出來，然后導進到數據軟件中往進行分析，辛苦程度自不用說；但這個苦楚的階段不會持續太久，哪兒有苦楚，哪兒就有生意，所以網站日志分析軟件就呈現了，解決了很大的標題，以至于大小互聯網服務供給商（ISP）們都為租用他們空間的用戶供給一款免費的網站日志分析軟件。盡管如此，分析網站日志一直都是一個相當不輕易的事情，所以，人們不得不尋找一些更方便的方法，這樣便發明了網站分析的新的數據獲取方法，這是后話了。
假如你問我什么情況下選擇用網站服務器日志來進行網站分析，我建議你如非必需，那么還是尋找一些更輕易的方法能夠事半功倍。看看后面的內容，你就能知道我為什么這么說。
2. 用網站服務器日志進行網站分析的長處
盡管是個技巧活，但是利用網站服務器日志進行網站分析還是有不少利益的。
1. 網站服務器的日志是被你完整掌控的數據。
所謂放在自己手心最放心，這些日志在你的服務器中，假如不是黑客進侵，數據不可能被你不盼看的人獲取。而且，只要你不刪除，它們永遠都在那里，在任何時候你都可以回溯歷史數據，無論這些數占領多么久遠。有朝一日，你的網站大獲成功，這些日志也是一份奮斗歷史的見證。
2. 能夠記錄機器人/主動程序對網站的拜訪。
其次，前面講過，網站服務器的日志是記錄網站服務器行動的，因此任何服務器響應的懇求都會被記錄下來。這些響應可能是應答用戶發出的懇求，也完整可能是應答一些互聯網上主動程序發出的懇求。最常見的一種互聯網上的主動程序是搜索引擎的機器人，例如Google的Googlebot，這意味著網站服務器日志能夠用來分析搜索引擎的拜訪，并幫助我們優化搜索引擎對網站的拜訪。講到這里，請大家注意，并不是每一種網站分析方法都能做到這一點，我們最常用的為網站頁面參加標簽的方法是不能獲取搜索引擎流量的。
3. 終端無關
網站服務器的日志能夠記錄網站服務器全部響應行動的特點還延伸出另外一個長處，那就是無論是何種終端拜訪服務器，都能把相干數據記錄下來。現在，能夠拜訪網站的終端越來越多了，我無聊的時候也試著用Sony的PSP上網，用手機的GPRS也能輕松的瀏覽網頁，這些形形色色的終真個拜訪，服務器日志都會忠誠的記錄，但頁面參加標簽的方法就可能完整行不通。
4. 能夠探知文件是否完整下載
日志方法的另一個利益是能夠記錄文件下載的情況。假如你在網高低載一個MP3音樂，你在發出這個響應的時候，日志會記錄一個狀態；你在下載完整的時候，日志照樣會記錄一個狀態；假如你沒有下載完整，日志還是會記錄下來。這個，我想對那些供給下載服務的網站很有用。
5. 數據獲取不依附于第三方
通過日志獲取數據本身不需要額外的第三方的幫助。只要你的服務器在運轉，日志就會源源不斷的被創立、保留。不過，請注意，這里我所指的是數據的獲取不需要額外的支撐，但是數據的分析一般而言，還是需要第三方的幫助的。直接往用肉眼讀日志文件中的數據進行分析是不可想象的。
6. 不怕防火墻
最后，日志方法不害怕防火墻或客戶端安全軟件的屏蔽，由于數據都是從服務器端獲取的。
看起來似乎不錯，不過凡事有利有弊，日志方法也確定有它不能克服的不足。
3. 用網站服務器日志方法進行網站分析的毛病
日志方法能夠起到作用的條件是服務器要響應來自客戶真個懇求，假如客戶真個懇求不通過服務器就得到了響應（這實在是經常產生的），那么服務器日志法就無能為力了。
1. 害怕網頁緩存（Cache）
為了提高網站頁面的載進速度，人們發明了網頁緩存（Cache）。在臺灣，Cache被翻譯作“快取”，似乎兼備了音義。
網頁緩存的原理很輕易懂得，但卻是個了不起的發明。在緩存呈現之前，人們拜訪網站每次都需要把網頁從網站的服務器傳輸到客戶真個瀏覽器中，這個速度當然會有點兒慢，尤其是網絡條件不好的時候。于是善動頭腦的人們發明，每次拜訪的網站實在有很多內容是沒有更新的，假如能夠把那些不經常更新的部分放在自己的電腦里面，每次打開網頁的時候，首先搜索自己電腦里面已經有的內容，然后再往服務器往尋找那些被更新了的部分，這樣服務器傳輸的數據量就會大大減少了，全部網頁也會被更快地顯示出來。
現在，我們大部分人的瀏覽器都設置了緩存。所以，有時候，你會發明，即使網絡沒有接通，你拜訪的網站似乎也能“正常”打開，只不過瀏覽器會顯示“脫機”狀態，告訴你，這些內容不是真正從服務器傳輸過來的。
除了客戶端（瀏覽器）能夠存放緩存的內容外，代理服務器（Proxy）也能夠存放網頁緩存，目標同樣是為了提速。你可以把代理服務器的緩存想象成CPU的“二級緩存”——當客戶端沒有存儲某個網頁的緩存的時候（“一級緩存”沒有內容），瀏覽器就會尋找代理服務器緩存，看看有沒有內容。假如還沒有，那才會再往尋找真正存放網頁內容的網站服務器。
有了緩存，當你點擊瀏覽器的“回退按鈕”的時候，回退的上一個頁面就不需要再重新從服務器中下載一次，而是立即就浮現在你的眼前。你常用的網站的打開速度也明顯晉升了。
可是，對于通過服務器日志來獲取網站拜訪數據的方法而言，這可不是一個好事情。由于緩存的存在，本來應當懇求服務器的成果不需要懇求了，服務器的日志什么也不會記錄下來，可是對頁面的拜訪卻又實實在在的產生了。
所以，緩存的存在會使日志方法低估網站的實際拜訪量。
2. 害怕Flash等“客戶端交互”內容
現在，為了更具沖擊力的視覺后果和更豐富的網頁互動，應用Flash、參加視頻、設計很多互動程序在網頁上已經稀疏平常。而這些元素，它們太獨立了，以至于當它們被載進到瀏覽器端了之后，完整可以在瀏覽器端運行而不再與服務器產生交互，或者只需要在必要的時候才與服務器產生交互。
比如，你玩兒普通網頁版的Flash小游戲，一旦游戲下載完畢，你在玩兒的過程中跟網站服務器就不會有什么接洽了，或者你看網頁上的視頻，你在播放器上進行的暫停把持，一般也不會跟服務器進行互動。還有，有一些腳本語言編寫的網頁程序，是在瀏覽器上被說明履行的，比如用JavaScript實現的網頁Tab標簽切換，在頁面全部載完后，無論你怎么切換Tab，服務器都感到不到了。
服務器感到不到，也就不會存在什么服務器日志記錄，也就不會有數據，因此用日志方法是無法準確獲取“客戶端交互”類型的網站拜訪行動的。這種情況下，必需選擇其他的數據收集方法。
3. 不準確的拜訪者記錄
日志方法分辨獨立拜訪者需要依附客戶真個IP地址，也只能依附它。不過，IP地址顯然不代表真正的拜訪者。上班族的全部辦公室的IP地址都可能是一個（應用代理服務器），而這個辦公室可能坐著十多個人。這可能使拜訪者的數目被低估。
同樣，在家中，假如你購置了公共網絡服務，那么你的IP地址存在動態分配的標題。你今天上網的IP地址和明天的可能就會不同，這個時候日志方法只能判定為兩個不同的拜訪者。這又可能使拜訪者的數目被高估。
此外，前面提到過日志是能夠忠誠記錄機器（非人為）的拜訪運動的，但是機器不是人，它們的運動混在真實的人的拜訪之中，同樣會使真實拜訪者的數目，或者拜訪數本身被高估。
在這正反兩相反方向的共同作用下，成果只能一個，那就是對于拜訪者數目標估算是非常含混的。當然，我們必需要承認，無論用什么方法，網站拜訪者的準確數目都無法獲得，但相對而言，日志方法要更不準確些。
4. 較弱的實時性
沒錯，網站服務器日志是記錄服務器運行的實時數據的，但是這些數據想要被取出分析，實時性就沒有那么好了。常見的情況是，你必需首先把服務器日志文件（log file）從服務器中取出來，而這些文件確定不會是服務器正在運行過程中的數據，一般都是隔天的（需要驗證），然后再把這些日志文件導進到專門針對日志分析的工具中才干進行分析。這個過程的快慢依附于你的熟練程度，但要尋求實時，頗有難度。
有技巧高超的站長或者工程師通過架設內部網絡、組建專門的日志分析服務器，并且編寫特定的程序來解決日志分析的實時性標題（http://www.phparticle.net/htmldata/36462/1/），但是，對于普通的中小網站，這種方法難度頗大，花費不菲，所以可行性不強。因此，實時性是盡大部分通過日志方法來分析網站數據時要面對的標題。
5. 海量的數據存儲
服務器日志是忠誠的，所以它會如實記錄下來每一分每一秒產生的每一條服務器響應。對于一些流量稍大的網站，一天的網站日志記錄超過數個G（Gigabytes）是非常正常的，而那些最大的網站，一個小時就可能產生數G的記錄。我們沒有詹姆斯·卡梅隆的超級團隊（他的《阿凡達》殊效需要處理超過500，000G的數據），所以假如要回溯網站一個月的流量就可能變成一個相當棘手的標題，需要投進相當的時間和耐心，假如你沒有相當的技巧和經驗，效率就會很低。
6. 日志文件獲取繁瑣
我們不能把日志文件的獲取想象的太簡略，畢竟這不是在自己臥室的電腦中點開一個MP3文件那么輕易。有些網站有鏡像服務器，有些服務器在境外，有些服務器是由處在多個不同地理地位的物理服務器邏輯組合而成。這些情況下，在進行日志分析之前需要集中所有的日志文件，這是一個很有些麻煩的事情，尤其是當日志文件的體積極為宏大的時候。另外，假如是租用的ISP服務器空間，假如沒有權限獲取日志數據，那么實際上連進行分析的可能性都沒有了。
現在，你完整懂得了日志方法收集網站分析數據的優毛病，那么，什么情況下你應當選擇這種方法進行網站分析呢？
4. 什么情況下該用日志分析方法
假如你有如下的數據監測和分析的需要，你應當用日志分析方法：
1. 需要懂得搜索引擎機器人或者其他非人為拜訪流量，并且盼看據此對網站進行針對性的優化，如通過火析搜索引擎的拜訪行動來進行SEO；
2. 需要懂得除了普通的PC客戶端之外的上網設備對網站的拜訪情況；
3. 需要懂得網站的文件資源是否被用戶完整的下載索取；
4. 對網站流量信息具有極高的保密需要，不答應讓任何第三方染指或幫忙；
5. 對于網站服務器的安全性和可保護性有請求，以及有非常明顯的對抗黑客或其他非授權拜訪需求的。
假如有如下需求，你不應當用日志分析方法：
1. 你的網站有重要的Flash之類的“非網頁類型的互動”，用戶和這些內容的互動是你想要懂得的內容；
2. 不愛好麻煩，對大數據量文件的處理不擅長，對日志文件不熟悉，沒有好的日志數據處理軟硬件資源；
3. 需要更準確的懂得網站被真正的人拜訪的情況，而不需要懂得“非人”的機器對網站的拜訪并且不盼看受到網頁緩存的干擾；
4. 需要更好的實時性、更規律更直觀的數據浮現。
現在，拿著這個清單，你可以做出輕易的選擇了。由于我的博客（http://www.chinawebanalytics.cn）的流量很多來自搜索引擎，因此分析服務器日志并懂得搜索引擎爬蟲的工作實在是非常必要的一個分析工作之一。
就我的經驗而言，我們國家應用日志來分析網站仍然占領相當的比例，尤其是對于一些大型網站，他們會開發專門的軟件，劃撥專門的硬件資源來分析網站日志。不過，這不僅僅是從分析拜訪者行動的角度來考慮，更是從網站服務器的安全性和可保護性角度來考慮的。
不過，假如你把網站分析的重心放在對于網站真實拜訪者行動的追蹤和分析上，那么，通過日志方法來實現相對而言難度相對照較大，把持也比擬繁瑣，我們可以利用另一種方法，即頁面標記法（Page Tag）來實現對網站拜訪數據的收集。
好了，先容完了，盼看大家感到看完后還算高興！現在是大家的時間了，請您留言，任何標題，想法，不確實之處，都非常歡迎！謝謝！
［版權回Sidney Song（宋星）所有，歡迎轉載］
