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

接下來開始工作了，我們首先構(gòu)造第一個指令進(jìn)行查詢：根據(jù)上面的日志我們可以知道利用awk分析日志時(shí)HTTP狀態(tài)碼位于第九域也就是$9，而URI位于$7，那么首先我們合并上周的日志，從中提取出所有狀態(tài)碼為302的日志，同時(shí)將域名及URI進(jìn)行合并成完整的URL，最后我們拆分出返回302狀態(tài)碼最多的TOP10個的二級目錄，按訪問次數(shù)降序排序。由于當(dāng)時(shí)忘了截圖了，所以現(xiàn)在就手打下面的代碼供各位參考：
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個結(jié)果中發(fā)現(xiàn)abc（好吧，我可恥的打碼了）這個二級目錄格外搶眼，數(shù)量達(dá)到了2W，同時(shí)我對比了上上周302的數(shù)據(jù)，發(fā)現(xiàn)之前abc目錄也有302的問題，只是數(shù)量級在1K左右，而且之前abc目錄下返回302的頁面是完全正確的。至此我開始懷疑abc二級目錄下存在有異常情況，同時(shí)由于abc二級目錄下的頁面數(shù)量依舊眾多，我們?nèi)绻朗蔷唧w哪類頁面有問題的話，還是得進(jìn)一步往下細(xì)分。我的思路很簡單，繼續(xù)挖URL的目錄層級確定問題出現(xiàn)的位置。
1，先計(jì)算abc目錄有多少次跳轉(zhuǎn)被百度爬蟲抓取到

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


3，在發(fā)現(xiàn)了出錯的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
通過上面的查詢發(fā)現(xiàn)了在不同二級域名的abc目錄下都存在同類錯誤URL(如domainname/abc/123/123)被爬蟲抓取到，那么可以肯定這個一定是個批量存在的問題，而且是模板上有錯誤導(dǎo)致大量頁面受影響，而絕不是個別頁面出錯。
既然如此我們可以順藤摸瓜了，最終發(fā)現(xiàn)問題是出現(xiàn)在了產(chǎn)品頁的相關(guān)產(chǎn)品鏈接模塊上，在前一周上線相關(guān)功能時(shí)研發(fā)部同事為了省事，直接將此處的a標(biāo)簽寫成了這種格式的相對路徑(<a href="123456">xxx</a>)，那么當(dāng)用戶訪問的當(dāng)前URL為domainname/abc/123的情況下這類相對路徑在補(bǔ)全之后會變成domainname/abc/123456，這個URL是正確的。但不巧的是，上線該功能的時(shí)候研發(fā)同時(shí)調(diào)整了rewrite規(guī)則，導(dǎo)致原先domainname/abc/123/這種不規(guī)范URL301跳轉(zhuǎn)到標(biāo)準(zhǔn)化的不帶斜杠的URL規(guī)則由于被覆蓋而失效了，結(jié)果就是domainname/abc/123/竟然返回了200代碼，而要命的是，相對路徑在這種情況下就被補(bǔ)全為domainname/abc/123/123456了，也就是我們?nèi)罩痉治鲋凶詈蟀l(fā)現(xiàn)的錯誤URL形式。而這類錯誤的URL則又莫名其妙的匹配到了301和302的rewrite規(guī)則，于是乎錯誤抓取量一發(fā)不可收拾。當(dāng)時(shí)的截圖如下：

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