最近發現服務器上的磁盤空間不足，檢查發現是被IIS日誌佔用掉了，因爲服務器運行到現在日誌一直沒有歸檔，一天下來的日誌有三四百M，到現在都好幾十個GB，所以這兩週專門研究怎麼處理這些日誌，在中國開源社區找來下，發現一款免費的WEB日誌分析軟件AWStats，功能很齊全，爲了更多的瞭解這個軟件，在網上找這方面的資料，發現了車東大哥的個人博客，上面介紹了好多這方面的資料，此文爲其中的一篇
你完全不用耐心的看完後面所有的說明，awstats在進行日誌統計時，
命令行統計增加： -databasebreak=day
報表輸出時增加： &databasebreak=day&day=DD
即可按天進行統計, 解決按月統計，歸檔數據過大導致統計過慢/失敗的問題。
問題：
很多網站在流量從10萬級增加到百萬級以後就放棄了awstats作爲統計，具體表現就是到月底的時候，統計數據會運行1天都運行不完。於是就改爲webalizer或者analog了。其實這並非awstats統計效率不高：awstats很多豐富的統計指標：蜘蛛識別 瀏覽器識別，文件類型統計等，都是比Webalizer豐富的，Webalizer要實現類似的統計力度也會出現性能問題。
原因分析：
性能的瓶頸在哪裏呢：awstats統計缺省時按月統計，到月底時候記住的頭20多天的歷史IP等累計統計指標，會使得DUMP數據文件變得很大（數百M），而awstats運行時，需要的內存量是dump數據文件的3－4倍。當這個monthly積累的數據導致awstats統計腳本載入內存的數據量過大，用到系統文件交換做內存的時候日誌統計效率就會降低了（處理速度會低2-3個數量級），於是出現了運行一天都統計不完前一天日誌的現象。
解決：
AWStats豐富的統計指標還是很有用的，而一個網站已經達到日千萬級的訪問請求，按天的詳細的數據統計也是必須的了。所以：索性犧牲一下按月的獨立IP統計，將日誌改成按天統計，如果需要按月的彙總，可以利用awstats的dump數據成爲一箇中間數據源彙總統計。
其他問題：
1 按天的報表瀏覽：用Calendar.php做個日曆瀏覽界面；
按天統計後，awstats的輸出文件會變成awstatsMMYYYYDD.confname.txt 每天一個統計文件，而報表的輸出需要增加 &databasebreak=day&day=DD 來指定某一天的數據。增加了日期後，awstats的報表輸出有些不方便，awstats本身沒有提供按日的瀏覽，可以自己做個日曆前端，方便awstats的報表瀏覽。
2 日誌數據源：最好是壓縮的，因爲日誌上2G以後，文件系統出問題的可能性大。儘量還是壓縮日誌後，通過zcat管道給awstats進行統計；
類似的思路：
1 如果 databasebreak=day 仍然無法解決問題， 排除掉次要統計指標：過濾掉圖片 js css等文件的請求日誌；
2 如果仍然沒有辦法解決問題： 設置爲小時級別截斷 databasebreak=hour 然後用每天的同一個小時（比如：下午5點－6點）做爲1天的抽樣，進行每天的數據跟蹤；
總之：爲了統計精度/完整性犧牲重要的統計統計指標是不值得的。當流量提高到百萬級別，即使損失了n%的精度，對於做出結論已經足夠了。而且利用awstats 的dump data作爲中間處理結果，進行數據挖掘也是很方便的（大部分是CSV，分項的很容易用grep截取分離出來）。
作者：車東 發表於：2007-03-07 21:03 最後更新於：2007-12-19 09:12版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本版權聲明。
http://www.chedong.com/blog/archives/001293.html