網站運營中有一個環節至關重要，那就是數據監控及數據分析，否則出問題都不知道出在哪里。而爬蟲日志分析做為數據監控及分析的一部分是所有SEO技術中最基礎的，但是卻不是最簡單的。說基礎是因為所有的科學的SEO策略都必須依賴于數據分析，而日志是為數不多的能直接了解搜索引擎和我們網站發生了哪些交互的渠道之一而且是流量到達之前的第一手數據。說不簡單是因為數據的存儲及處理上，日志從幾十MB，幾百MB，幾個GB，幾十個GB，幾百個GB，幾個TB用到的工具及部署難度是完全不同的：幾十MB用ultraedit等文本編輯器都可以做到數據的拆分；幾百MB的時候得用shell；而如果是幾個GB可以開始考慮利用Mysql或者其他行存儲的數據庫來存儲字段切分后的結構化日志了；幾百個GB可以上Infobright或者其他列存儲的數據庫了；如果達到TB那只有Hadoop的hive能夠解決了，目前在用Hive的SEOer我所知道的只有趕集網的zero大神了。
對于99%的站長朋友來說，shell用于處理日志已經很稱職了，我目前用的也是shell。這里簡單介紹一下shell的概念，shell可以理解成*nix系統的cmd命令行，而日志拆分中常用的shell指令有cat以及awk（實際上grep用的也很多，只是本文為了控制篇幅就不多介紹了）。cat實際的作用是合并多個文件并且將標準輸出(stdout)的結果打印到屏幕上。而awk指令其實當成編程語言都可以寫一本書的，他的特色就是可以按照分隔符切分文本字段并且處理，默認的分隔符為空格。以上兩個指令網上資料一堆，建議各位都花時間學習一下。
言歸正傳，作為網站運營的數據據監控體系的一部分，我們公司建立一個全自動爬蟲日志分析的系統，功能上可以參考夜息的博文來看。全自動化日志分析腳本很好的起到了監控及預警的作用，但不是萬能的，日志如果出現莫名其妙的錯誤，就還是得自己動手豐衣足食。在去年12月第二周的周日志監控報表中，百度爬蟲的301及302響應碼的抓取量大幅增長，這部分異常抓取量加一起一周漲了6w！因為一定時間內蜘蛛的抓取量是恒定的，那么錯誤頁面的抓取上漲代表著其他頁面抓取的下降，在本例中，內頁受影響最大。抓取量發生如此劇烈波動意味著肯定有地方出問題了，所以我們第一步需要確定的是具體哪些頁面出現了問題。
貼一條日志記錄（目的是幫助大家定位下面實例中awk具體的域分別是哪些，由于有競業保密協議，所以下面的關鍵部分我打碼了）：

接下來開始工作了，我們首先構造第一個指令進行查詢：根據上面的日志我們可以知道利用awk分析日志時HTTP狀態碼位于第九域也就是$9，而URI位于$7，那么首先我們合并上周的日志，從中提取出所有狀態碼為302的日志，同時將域名及URI進行合并成完整的URL，最后我們拆分出返回302狀態碼最多的TOP10個的二級目錄，按訪問次數降序排序。由于當時忘了截圖了，所以現在就手打下面的代碼供各位參考：
cat 20121203.txt 20121204.txt 20121205.txt 20121206.txt 20121207.txt 20121208.txt 20121209.txt | awk '{if($9 —— "302")print $16$7}' | awk -F"//" '{print $2}' | sort | uniq -c | sort -nr | head -n10
在10個結果中發現abc（好吧，我可恥的打碼了）這個二級目錄格外搶眼，數量達到了2W，同時我對比了上上周302的數據，發現之前abc目錄也有302的問題，只是數量級在1K左右，而且之前abc目錄下返回302的頁面是完全正確的。至此我開始懷疑abc二級目錄下存在有異常情況，同時由于abc二級目錄下的頁面數量依舊眾多，我們如果要知道是具體哪類頁面有問題的話，還是得進一步往下細分。我的思路很簡單，繼續挖URL的目錄層級確定問題出現的位置。
1，先計算abc目錄有多少次跳轉被百度爬蟲抓取到

2，多加一個判斷條件，判斷出問題的URL目錄層級具體是第幾層


3，在發現了出錯的URL的目錄層級后，我們將這部分出錯的URL提取個100條出來看看
cat 20121203.txt 20121204.txt 20121205.txt 20121206.txt 20121207.txt 20121208.txt 20121209.txt | awk '{if($9 —— "302")print $16$7}' | awk -F"//" '{if($2 —— "abc" && $4)print $0}' | head -n100
通過上面的查詢發現了在不同二級域名的abc目錄下都存在同類錯誤URL(如domainname/abc/123/123)被爬蟲抓取到，那么可以肯定這個一定是個批量存在的問題，而且是模板上有錯誤導致大量頁面受影響，而絕不是個別頁面出錯。
既然如此我們可以順藤摸瓜了，最終發現問題是出現在了產品頁的相關產品鏈接模塊上，在前一周上線相關功能時研發部同事為了省事，直接將此處的a標簽寫成了這種格式的相對路徑(<a href="123456">xxx</a>)，那么當用戶訪問的當前URL為domainname/abc/123的情況下這類相對路徑在補全之后會變成domainname/abc/123456，這個URL是正確的。但不巧的是，上線該功能的時候研發同時調整了rewrite規則，導致原先domainname/abc/123/這種不規范URL301跳轉到標準化的不帶斜杠的URL規則由于被覆蓋而失效了，結果就是domainname/abc/123/竟然返回了200代碼，而要命的是，相對路徑在這種情況下就被補全為domainname/abc/123/123456了，也就是我們日志分析中最后發現的錯誤URL形式。而這類錯誤的URL則又莫名其妙的匹配到了301和302的rewrite規則，于是乎錯誤抓取量一發不可收拾。當時的截圖如下：

既然問題根源已經找到了，接下來就是制定解決方案：
1，修改產品頁模板：對相關產品鏈接使用根目錄起始的相對路徑(也就是<a href="/abc/123456">xxx</a>)；
2，增加URL標準化的rewrite規則：將帶斜杠的網址301到不帶斜杠的標準網址(Rewriterule ^/abc/([0-9]+)/$ /abc/$1 [R=301,L])
3，由于百度對301反應很慢，所以需要利用百度站長平臺中的網站改版工具的高級改版規則來加強URL標準化效果：替換規則為abc/#/<>，然后再填入兩個樣例幫助百度匹配下即可。這里可以簡單說一下，替換規則中的#代表著任意數字，在我們這個實例中代表產品頁的數字id，而最后的<>則是將<>中的內容，此處其中為空，直接替換掉最近匹配到的文字，也就是URL結尾的斜杠。但是可惜的是如果遇到的標準URL是帶斜杠的/abc/123/這種，那就沒法使用百度改版工具來做了，因為目前的站長改版工具的規則很刻板，也不像正則可以用后向引用，所以這種情況就只有