服務器日志網站分析的原理及優缺點

　　【前言】

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

　　【正文】

　　網站分析收集數據的方式其實有五、六種之多，我們最常見的有三種，分別是：服務器日志(Server Log)、頁面標記(Page Tag)和客戶端監測軟件收集?lient 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。關于cookie的內容請大家看我的這篇文章：捍衛Cookie――沒有Cookie，我們什么都沒有了。

　　看起來，網站服務器日志所記錄的內容是很有限的，比起我們動輒上萬行的編程實在是九牛一毛。但是，千萬別認為網站服務器日志文件會很小，對于一些大網站，每分每秒都有很多訪問者對網站服務器進行請求，所以日志文件會積少成多，成為巨型的數據文件。有時候，一個小時的記錄就能超過數G。什么，你網站的服務器日志一個月才1M?要加油啊，沒有人氣的網站可沒有生命力。

　　講到這兒，該說說歷史了。網站分析就是從網站服務器日志開始的，或者更準確的說，網站服務器日志自誕生之日起，就是為網站分析所用的。最早，人們可是把所有的記錄都拿出來，然后導入到數據軟件中去進行分析，辛苦程度自不用說;但這個痛苦的階段不會持續太久，哪兒有痛苦，哪兒就有生意，所以網站日志分析軟件就出現了，解決了很大的問題，以至于大小互聯網服務提供商(ISP)們都為租用他們空間的用戶提供一款免費的網站日志分析軟件。盡管如此，分析網站日志一直都是一個相當不容易的事情，所以，人們不得不尋找一些更便利的方法，這樣便發明了網站分析的新的數據獲取方法，這是后話了。

原文轉自：http://blogread.cn/it/article/1891?f=wb