應朋友們的要求，我還是寫一篇關于服務器網站日志分析的原理及優缺點是什么。請朋友們注意，網站服務器日志法并不容易進行，初學者，以及在絕大多數情況下，進行以用戶行為分析為核心的網站分析，用不到服務器日志法。不過，作為網站分析歷史不可分割的一部分以及重要的基礎篇章，服務器日志法仍然值得一書。下面的這篇文章也是我要撰寫的書中截取的內容(我要快馬加鞭快快寫了，已經辜負了太多朋友的重托，抱歉抱歉!)。

　　【正文】

　　網站分析收集數據的方式其實有五、六種之多，我們最常見的有三種，分別是：服務器日志(Server Log)、頁面標記(Page Tag)和客戶端監測軟件收集(Client End/Desktop)。

　　一. 服務器日志是什么

　　真正意義上的網站分析是從服務器日志開始的，而且直到今天，分析服務器(也稱為server log file，或簡稱log file)日志仍然是網站分析的重要方法。

　　這里的服務器指的是網站服務器(Web Server)，而服務器日志跟飛機的黑匣子一樣，是用來記錄網站服務器的運行信息的，或者簡單說，是用來記錄服務器中的什么頁面在什么時候被誰訪問了。例如，如果你訪問一次模板無憂網站：http://m.ghpqjb.com，那么一般情況下，網站服務器的日志就會記錄在某時某刻來自某個IP的訪問者索引了網頁“/index.html”。當然，網站服務器日志還會記錄其他許多內容，這些內容能夠幫助我們分析網站的流量和訪問者在網站上的行為。

　　下面這個圖說明了網站日志是如何產生的。當用戶訪問一個網站的時候，事實上是訪問這個網站的某一個具體的頁面，我們假設這個頁面叫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)們都為租用他們空間的用戶提供一款免費的網站日志分析軟件。盡管如此，分析網站日志一直都是一個相當不容易的事情，所以，人們不得不尋找一些更便利的方法，這樣便發明了網站分析的新的數據獲取方法，這是后話了。

　　如果你問我什么情況下選擇用網站服務器日志來進行網站分析，我建議你如非必須，那么還是尋找一些更容易的方法能夠事半功倍。看看后面的內容，你就能知道我為什么這么說。

　　二. 用網站服務器日志進行網站分析的優點

　　盡管是個技術活，但是利用網站服務器日志進行網站分析還是有不少好處的。

　　1. 網站服務器的日志是被你完全掌控的數據。

　　所謂放在自己手心最放心，這些日志在你的服務器中，如果不是黑客入侵，數據不可能被你不希望的人獲取。而且，只要你不刪除，它們永遠都在那里，在任何時候你都可以回溯歷史數據，無論這些數據有多么久遠。有朝一日，你的網站大獲成功，這些日志也是一份奮斗歷史的見證。

　　2. 能夠記錄機器人/自動程序對網站的訪問。

 

　　其次，前面講過，網站服務器的日志是記錄網站服務器行為的，因此任何服務器響應的請求都會被記錄下來。這些響應可能是應答用戶發出的請求，也完全可能是應答一些互聯網上自動程序發出的請求。最常見的一種互聯網上的自動程序是搜索引擎的機器人，例如Google的Googlebot，這意味著網站服務器日志能夠用來分析搜索引擎的訪問，并幫助我們優化搜索引擎對網站的訪問。講到這里，請大家注意，并不是每一種網站分析方法都能做到這一點，我們最常用的為網站頁面加入標簽的方法是不能獲取搜索引擎流量的。

　　3. 終端無關

　　網站服務器的日志能夠記錄網站服務器全部響應行為的特點還延伸出另外一個優點，那就是無論是何種終端訪問服務器，都能把相關數據記錄下來。現在，能夠訪問網站的終端越來越多了，我無聊的時候也試著用Sony的PSP上網，用手機的GPRS也能輕松的瀏覽網頁，這些形形色色的終端的訪問，服務器日志都會忠實的記錄，但頁面加入標簽的方法就可能完全行不通。

　　4. 能夠探知文件是否完全下載

　　日志方法的另一個好處是能夠記錄文件下載的情況。如果你在網上下載一個MP3音樂，你在發出這個響應的時候，日志會記錄一個狀態;你在下載完全的時候，日志照樣會記錄一個狀態;如果你沒有下載完全，日志還是會記錄下來。這個，我想對那些提供下載服務的網站很有用。

　　5. 數據獲取不依賴于第三方

　　通過日志獲取數據本身不需要額外的第三方的幫助。只要你的服務器在運轉，日志就會源源不斷的被創建、保存。不過，請注意，這里我所指的是數據的獲取不需要額外的支持，但是數據的分析一般而言，還是需要第三方的幫助的。直接去用肉眼讀日志文件中的數據進行分析是不可想象的。

　　6. 不怕防火墻

　　最后，日志方法不懼怕防火墻或客戶端安全軟件的屏蔽，因為數據都是從服務器端獲取的。

　　看起來似乎不錯，不過凡事有利有弊，日志方法也肯定有它不能克服的不足。

　　三. 用網站服務器日志方法進行網站分析的缺點

　　日志方法能夠起到作用的前提是服務器要響應來自客戶端的請求，如果客戶端的請求不通過服務器就得到了響應(這其實是經常發生的)，那么服務器日志法就無能為力了。

 

 

　　1. 害怕網頁緩存(Cache)

　　為了提高網站頁面的載入速度，人們發明了網頁緩存(Cache)。在臺灣，Cache被翻譯作“快取”，似乎兼備了音義。

　　網頁緩存的原理很容易理解，但卻是個了不起的發明。在緩存出現之前，人們訪問網站每次都需要把網頁從網站的服務器傳輸到客戶端的瀏覽器中，這個速度當然會有點兒慢，尤其是網絡條件不好的時候。于是善動腦筋的人們發現，每次訪問的網站其實有很多內容是沒有更新的，如果能夠把那些不經常更新的部分放在自己的電腦里面，每次打開網頁的時候，首先搜索自己電腦里面已經有的內容，然后再去服務器去尋找那些被更新了的部分，這樣服務器傳輸的數據量就會大大減少了，整個網頁也會被更快地顯示出來。

　　現在，我們大部分人的瀏覽器都設置了緩存。所以，有時候，你會發現，即使網絡沒有接通，你訪問的網站似乎也能“正常”打開，只不過瀏覽器會顯示“脫機”狀態，告訴你，這些內容不是真正從服務器傳輸過來的。

　　除了客戶端(瀏覽器)能夠存放緩存的內容外，代理服務器(Proxy)也能夠存放網頁緩存，目的同樣是為了提速。你可以把代理服務器的緩存想象成CPU的“二級緩存”——當客戶端沒有存儲某個網頁的緩存的時候(“一級緩存”沒有內容)，瀏覽器就會尋找代理服務器緩存，看看有沒有內容。如果還沒有，那才會再去尋找真正存放網頁內容的網站服務器。

 

　　有了緩存，當你點擊瀏覽器的“回退按鈕”的時候，回退的上一個頁面就不需要再重新從服務器中下載一次，而是立即就呈現在你的面前。你常用的網站的打開速度也顯著提升了。

　　可是，對于通過服務器日志來獲取網站訪問數據的方法而言，這可不是一個好事情。由于緩存的存在，本來應該請求服務器的結果不需要請求了，服務器的日志什么也不會記錄下來，可是對頁面的訪問卻又實實在在的發生了。

　　所以，緩存的存在會使日志方法低估網站的實際訪問量。

　　2. 害怕Flash等“客戶端交互”內容

　　現在，為了更具沖擊力的視覺效果和更豐富的網頁互動，運用Flash、加入視頻、設計很多互動程序在網頁上已經稀疏平常。而這些元素，它們太獨立了，以至于當它們被載入到瀏覽器端了之后，完全可以在瀏覽器端運行而不再與服務器發生交互，或者只需要在必要的時候才與服務器發生交互。

　　比如，你玩兒普通網頁版的Flash小游戲，一旦游戲下載完畢，你在玩兒的過程中跟網站服務器就不會有什么聯系了，或者你看網頁上的視頻，你在播放器上進行的暫停操作，一般也不會跟服務器進行互動。還有，有一些腳本語言編寫的網頁程序，是在瀏覽器上被解釋執行的，比如用JavaScript實現的網頁Tab標簽切換，在頁面全部載完后，無論你怎么切換Tab，服務器都感覺不到了。

　　服務器感覺不到，也就不會存在什么服務器日志記錄，也就不會有數據，因此用日志方法是無法準確獲取“客戶端交互”類型的網站訪問行為的。這種情況下，必須選擇其他的數據收集方法。

　　3. 不精確的訪問者記錄

　　日志方法辨別獨立訪問者需要依靠客戶端的IP地址，也只能依靠它。不過，IP地址顯然不代表真正的訪問者。上班族的整個辦公室的IP地址都可能是一個(使用代理服務器)，而這個辦公室可能坐著十多個人。這可能使訪問者的數量被低估。

　　同樣，在家中，如果你購買了公共網絡服務，那么你的IP地址存在動態分配的問題。你今天上網的IP地址和明天的可能就會不同，這個時候日志方法只能判斷為兩個不同的訪問者。這又可能使訪問者的數量被高估。

　　此外，前面提到過日志是能夠忠實記錄機器(非人為)的訪問活動的，但是機器不是人，它們的活動混在真實的人的訪問之中，同樣會使真實訪問者的數量，或者訪問數本身被高估。

　　在這正反兩相反方向的共同作用下，結果只能一個，那就是對于訪問者數量的估算是非常模糊的。當然，我們必須要承認，無論用什么方法，網站訪問者的精確數量都無法獲得，但相對而言，日志方法要更不準確些。

 

 

　　4. 較弱的實時性

　　沒錯，網站服務器日志是記錄服務器運行的實時數據的，但是這些數據想要被取出分析，實時性就沒有那么好了。常見的情況是，你必須首先把服務器日志文件(log file)從服務器中取出來，而這些文件肯定不會是服務器正在運行過程中的數據，一般都是隔天的(需要驗證)，然后再把這些日志文件導入到專門針對日志分析的工具中才能進行分析。這個過程的快慢依賴于你的熟練程度，但要追求實時，頗有難度。

　　有技術高超的站長或者工程師通過架設內部網絡、組建專門的日志分析服務器，并且編寫特定的程序來解決日志分析的實時性問題，但是，對于普通的中小網站，這種方法難度頗大，花費不菲，所以可行性不強。因此，實時性是絕大部分通過日志方法來分析網站數據時要面對的問題。

　　5. 海量的數據存儲

　　

　　服務器日志是忠實的，所以它會如實記錄下來每一分每一秒發生的每一條服務器響應。對于一些流量稍大的網站，一天的網站日志記錄超過數個G(Gigabytes)是非常正常的，而那些最大的網站，一個小時就可能產生數G的記錄。我們沒有詹姆斯·卡梅隆的超級團隊(他的《阿凡達》特效需要處理超過500，000G的數據)，所以如果要回溯網站一個月的流量就可能變成一個相當棘手的問題，需要投入相當的時間和耐心，如果你沒有相當的技術和經驗，效率就會很低。

 

　　6. 日志文件獲取繁瑣

　　我們不能把日志文件的獲取想象的太簡單，畢竟這不是在自己臥室的電腦中點開一個MP3文件那么容易。有些網站有鏡像服務器，有些服務器在境外，有些服務器是由處在多個不同地理位置的物理服務器邏輯組合而成。這些情況下，在進行日志分析之前需要集中所有的日志文件，這是一個很有些麻煩的事情，尤其是當日志文件的體積極為龐大的時候。另外，如果是租用的ISP服務器空間，如果沒有權限獲取日志數據，那么實際上連進行分析的可能性都沒有了。

　　現在，你完全了解了日志方法收集網站分析數據的優缺點，那么，什么情況下你應該選擇這種方法進行網站分析呢?

　　四. 什么情況下該用日志分析方法

　　如果你有如下的數據監測和分析的需要，你應該用日志分析方法：

　　1. 需要了解搜索引擎機器人或者其他非人為訪問流量，并且希望據此對網站進行針對性的優化，如通過分析搜索引擎的訪問行為來進行SEO;

　　2. 需要了解除了普通的PC客戶端之外的上網設備對網站的訪問情況;

　　3. 需要了解網站的文件資源是否被用戶完整的下載索取;

　　4. 對網站流量信息具有極高的保密需要，不允許讓任何第三方染指或幫忙;

　　5. 對于網站服務器的安全性和可維護性有要求，以及有非常顯著的反抗黑客或其他非授權訪問需求的。

　　如果有如下需求，你不應該用日志分析方法：

　　1. 你的網站有重要的Flash之類的“非網頁類型的互動”，用戶和這些內容的互動是你想要了解的內容;

　　2. 不喜歡麻煩，對大數據量文件的處理不擅長，對日志文件不熟悉，沒有好的日志數據處理軟硬件資源;

　　3. 需要更精確的了解網站被真正的人訪問的情況，而不需要了解“非人”的機器對網站的訪問并且不希望受到網頁緩存的干擾;

　　4. 需要更好的實時性、更規律更直觀的數據呈現。

　　現在，拿著這個清單，你可以做出容易的選擇了。因為一個網站的流量很多來自搜索引擎，因此分析服務器日志并了解搜索引擎爬蟲的工作其實是非常必要的一個分析工作之一。

　　就我的經驗而言，我們國家使用日志來分析網站仍然占有相當的比例，尤其是對于一些大型網站，他們會開發專門的軟件，劃撥專門的硬件資源來分析網站日志。不過，這不僅僅是從分析訪問者行為的角度來考慮，更是從網站服務器的安全性和可維護性角度來考慮的。

　　不過，如果你把網站分析的重心放在對于網站真實訪問者行為的追蹤和分析上，那么，通過日志方法來實現相對而言難度相對比較大，操作也比較繁瑣，我們可以利用另一種方法，即頁面標記法(Page Tag)來實現對網站訪問數據的收集。

　　好了，介紹完了，希望大家覺得看完后還算愉快!現在是大家的時間了，請您留言，任何問題，想法，不確切之處，都非常歡迎!謝謝!