網站日志，準確來說是服務器日志。通過服務器日志，我們可以了解到用戶在什么IP、在什么分辨率的設備、什么時間、什么地區訪問了我們的網站，以及當時訪問的頁面是否正常。
對于我們網站而言，搜索引擎也是網站用戶之一。本文提到的網站日志分析，更多是在分析搜索引擎這種用戶。

下面是一條標準的log file記錄：

202.71.113.38 – - [03/Jan/2014:01:56:12 +0800] "GET /http://www.mahaixiang.cn/SEO/index.html HTTP/1.0" 200 5122

從左到右，202.71.113.38就是遠程主機的IP；而登錄名和登錄全名指的是發起這個請求的用戶的名字，這個一般大家是不想要透露的了，所以遠程主機會禁止給出這兩個信息，log file當然就記錄不下來了，用兩個短中劃線代替。

然后，03/Jan/2014是請求發生的日期，01:56:12則是具體時間，之后的+0800是指比格林威治時間要晚8個小時，就是我們北京時間了。

再之后的GET是請求的方法，另一種方法是POST，可以簡單理解為GET就是索取，POST就是提交。

接著www.mahaixiang.cn/SEO/index.html是被請求文件的地址，可以是絕對地址也可以是相對地址。

HTTP/1.0是請求所遵守的協議，這里的協議是HTTP 1.0，整個記錄的結尾是兩個數字，其中200表示一種請求的狀態，意思是請求一切正常（具體可查看馬海祥博客《解讀IIS日志中搜索引擎蜘蛛名稱代碼及爬尋返回代碼》的相關介紹）。

有時候這個數字會顯示為404（不明白怎么設置404的朋友，可查看馬海祥博客《你真的懂404頁面設置嗎》的相關介紹），相信大家一看到這個數字就頭痛，它表示請求的文件無法找到（file not found）；又有時候，這個數字會顯示為301，表示頁面被重新定向到了別的地址。

最后的一個數字5593，表示所請求的文檔的長度為5122 bytes。

通用格式其實很簡單，但是里面的這11類記錄往往不足夠幫助我們進行更深入的分析，因此其他的一些記錄被加入進來，其中最重要的一些是：

①、請求來源（Referrer）：指連接到被請求資源的網站的URL，如果請求時通過點擊一個鏈接時發生，那么這個項目就會被記錄；

②、客戶端（User Agent）：記錄用戶的瀏覽器或者發出請求的程序的相關信息；

③、所需時間（Time Taken）：從請求的發出到請求的資源全部傳輸完畢所需花費的時間；

④、Cookie：關于cookie的內容請大家看馬海祥博客《基于Cookie信息的互聯網精準廣告定向技術研究》的這篇文章，在此，也就不多講了。

看起來，網站服務器日志所記錄的內容是很有限的，比起我們動輒上萬行的編程實在是九牛一毛，但是，千萬別認為網站服務器日志文件會很小，對于一些大網站，每分每秒都有很多訪問者對網站服務器進行請求，所以日志文件會積少成多，成為巨型的數據文件。

有時候，一個小時的記錄就能超過數G的容量，如果你網站的服務器日志一個月才1M，那你就要加油了，沒有人氣的網站可沒有生命力。

利用網站服務器日志分析網站的優點

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

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

（1）、網站服務器的日志是被你完全掌控的數據

所謂放在自己手心才是最放心的，這些日志在你的服務器中，如果不是h客入侵，數據不可能被你不希望的人獲取（具體可查看馬海祥博客《如何通過IIS日志分析網站的隱形信息》的相關介紹）。

而且，只要你不刪除，它們永遠都在那里，在任何時候你都可以回溯歷史數據，無論這些數據有多么久遠，有朝一日，你的網站大獲成功，這些日志也是一份奮斗歷史的見證。

（2）、能夠記錄機器人或自動程序對網站的訪問

其次，前面講過，網站服務器的日志是記錄網站服務器行為的，因此任何服務器響應的請求都會被記錄下來，這些響應可能是應答用戶發出的請求，也完全可能是應答一些互聯網上自動程序發出的請求。

最常見的一種互聯網上的自動程序是搜索引擎的機器人，例如：百度的Baiduspider、Google的Googlebot，這意味著網站服務器日志能夠用來分析搜索引擎的訪問，并幫助我們優化搜索引擎對網站的訪問。

講到這里，馬海祥請大家注意，并不是每一種網站分析方法都能做到這一點，我們最常用的為網站頁面加入標簽的方法是不能獲取搜索引擎流量的。

（3）、各個終端訪問的詳細記錄

網站服務器的日志能夠記錄網站服務器全部響應行為的特點還延伸出另外一個優點，那就是無論是何種終端訪問服務器，都能把相關數據記錄下來。

現在，能夠訪問網站的終端越來越多了，我無聊的時候也試著用Sony的PSP上網，用手機的GPRS也能輕松的瀏覽網頁，這些形形色 色的終端的訪問，服務器日志都會忠實的記錄，但頁面加入標簽的方法就可能完全行不通。

（4）、能夠探知文件是否完全下載

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

（5）、數據獲取不依賴于第三方

通過日志獲取數據本身不需要額外的第三方的幫助，只要你的服務器在運轉，日志就會源源不斷的被創建、保存。

不過，請注意，這里我所指的是數據的獲取不需要額外的支持，但是數據的分析一般而言，還是需要第三方的幫助的，直接去用肉眼讀日志文件中的數據進行分析是不可想象的。

（6）、不怕防火墻

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

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

利用網站服務器日志分析網站的缺點

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

（1）、害怕網頁緩存

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

網頁緩存的原理很容易理解，但卻是個了不起的發明，在緩存出現之前，人們訪問網站每次都需要把網頁從網站的服務器傳輸到客戶端的瀏覽器中，這個速度當然會有點兒慢，尤其是網絡條件不好的時候。

于是善動腦筋的人們發現，每次訪問的網站其實有很多內容是沒有更新的，如果能夠把那些不經常更新的部分放在自己的電腦里面，每次打開網頁的時候，首先搜索自己電腦里面已經有的內容，然后再去服務器去尋找那些被更新了的部分，這樣服務器傳輸的數據量就會大大減少了，整個網頁也會被更快地顯示出來。

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

除了客戶端（瀏覽器）能夠存放緩存的內容外，代理服務器（Proxy）也能夠存放網頁緩存，目的同樣是為了提速。

你可以把代理服務器的緩存想象成CPU的“二級緩存”——當客戶端沒有存儲某個網頁的緩存的時候（“一級緩存”沒有內容），瀏覽器就會尋找代理服務器緩存，看看有沒有內容，如果還沒有，那才會再去尋找真正存放網頁內容的網站服務器。

有了緩存，當你點擊瀏覽器的“回退按鈕”的時候，回退的上一個頁面就不需要再重新從服務器中下載一次，而是立即就呈現在你的面前，你常用的網站的打開速度也顯著提升了（具體可查看馬海祥博客《如何實現shtml頁面的局部緩存》的相關介紹）。

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

（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服務器空間，如果沒有權限獲取日志數據，那么實際上連進行分析的可能性 都沒有了。