注：寫得有點亂，但目前市面上這方面內容的確不多，mark一下~
http://blog.csdn.net/pkueecser/article/details/9569251
大數據應用--系統監控與日誌分析
http://wenku.baidu.com/link?url=8CJ-URMjVTVaw3GM1AZ2w9A7V0CIeRz3dx7xvysILLk6IdWpJGT889gQ7-824G4hAK-T2tdqZY1Lo6CEN1hgqHQNlHhVFykWJ_9XQW6EN5K
大數據日誌分析產品（電商方向）
https://www.sensorsdata.cn/manual/event_ana.html
=============
日誌在計算機系統中是一個非常廣泛的概念，任何程序都有可能輸出日誌：操作系統內核、各種應用服務器等等。日誌的內容、規模和用途也各不相同，很難一概而論。
本文討論的日誌處理方法中的日誌，僅指Web日誌。其實並沒有精確的定義，可能包括但不限於各種前端Web服務器——apache、lighttpd、tomcat等產生的用戶訪問日誌，以及各種Web應用程序自己輸出的日誌。
在Web日誌中，每條日誌通常代表着用戶的一次訪問行爲，例如下面就是一條典型的apache日誌：
211.87.152.44 – - [18/Mar/2005:12:21:42 +0800] “GET / HTTP/1.1″ 200 899 “http://www.baidu.com/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon)”
從上面這條日誌中，我們可以得到很多有用的信息，例如訪問者的IP、訪問的時間、訪問的目標網頁、來源的地址以及訪問者所使用的客戶端的UserAgent信息等。如果需要更多的信息，則要用其它手段去獲取：例如想得到用戶屏幕的分辨率，一般需要使用js代碼單獨發送請求；而如果想得到諸如用戶訪問的具體新聞標題等信息，則可能需要Web應用程序在自己的代碼裏輸出。
爲什麼要分析日誌
毫無疑問，Web日誌中包含了大量人們——主要是產品分析人員會感興趣的信息，最簡單的，我們可以從中獲取網站每類頁面的PV值（PageView，頁面訪問量）、獨立IP數（即去重之後的IP數量）等；稍微複雜一些的，可以計算得出用戶所檢索的關鍵詞排行榜、用戶停留時間最高的頁面等；更復雜的，構建廣告點擊模型、分析用戶行爲特徵等等。
既然這些數據是如此的有用，那麼當然已經有無數現成的工具可以幫助我們來分析它們，例如awstats、Webalizer，都是專門用於統計分析Web服務器日誌的免費程序。
另外還有一類產品，它們不分析直接日誌，而是通過讓用戶在頁面中嵌入js代碼的方式來直接進行數據統計，或者說我們可以認爲它是直接讓日誌輸出到了它們的服務器。典型的代表產品——大名鼎鼎的Google Analytics，另外還有國內的cnzz、百度統計等。
很多人可能會說，既然如此，我們爲什麼還需要自己來分析日誌，有必要嗎？當然有。我們的用戶（產品分析人員）需求是無窮盡的，上面說的這幾類工具雖然很好很強大，但顯然沒辦法滿足全部的需求。
無論是本地分析的工具，還是在線的分析服務，它們雖然提很豐富的的統計分析功能，可以做一定程度的配置，但是依然很有限的。要進行稍複雜點的分析，或者要做基於日誌的數據挖掘，依然需要自己來完成。
另外絕大多數日誌分析工具都是隻能用於單機的，數據量稍大就沒轍了。同時那些提供在線分析的服務對於單個站點通常也都有最大流量的限制——這是很容易理解的，他們也需要考慮服務器的負載。
所以，很多時候還是得靠自己。
怎麼進行日誌分析
這並不是一個簡單的問題。即使我們把“日誌”限定爲Web日誌，依然包含了成千上萬種可能的格式和數據，而是“分析”更是難以定義，也許是簡單的統計值的計算，也許是複雜的數據挖掘算法。
下面並不打算討論這些複雜的問題，而只是籠統的討論如何構建進行日誌分析工作的基礎。有了這些基礎會讓基於日誌的簡單統計分析變得很簡單，並讓複雜的分析挖掘等變得可行。
少量數據的情況
先考慮最簡單的情況，在數據規模比較小的時候，也許是幾十MB、幾百MB或者幾十GB，總之就是在單機處理尚能忍受的時候。一切都很好辦，現成的各種Unix/Linux工具——awk、grep、sort、join等都是日誌分析的利器，如果僅僅是想知道某個頁面的PV，一個wc+grep就能搞定。如果有稍複雜的邏輯，那就使用各種腳本語言，尤其是perl，配合偉大的正則表達式，基本就可以解決所有的問題。
例如，我們想從上面提到的apache日誌中得到訪問量最高前100個IP，實現很簡單：
cat logfile | awk ‘{a[$1]++} END {for(b in a) print b”\t”a[b]}’|sort -k2 -r|head -n 100
不過當我們需要頻繁去分析日誌的時候，上面的做法在一段時間之後可能就會讓我們頭疼如何進行各種日誌文件、用於分析的腳本文件、crontab文件等等的維護，並且可能會存在大量重複的代碼來做數據格式的解析和清洗，這個時候也許就需要更合適的東西，比如——數據庫。
當然，要使用數據庫來進行日誌分析還是需要一些代價的，最主要的就是如何將各種異構的日誌文件導入的數據庫中——這個過程通常稱爲ETL（Extraction-Transformation-Loading）。幸好依然有各種現成的開源、免費的工具來幫助我們做這件事情，並且在日誌種類不太多的時候，自己寫幾個簡單的腳本來完成這項工作也並不困難。例如可以將上面的日誌去掉不必要的字段，然後導入如下的數據庫中：
現在需要考慮一下用什麼數據庫來存儲這些數據。MySQL是一個很經典的開源數據庫，它的傳統引擎（MyISAM或者InnoDB，行存儲）也許並不非常的適合日誌數據的存儲，但是在小數據量的時候還是很夠用的。而且，在這方面現在已經有了更好的選擇，例如開源且免費的Infobright、Infinidb，都是專門爲數據倉庫應用而進行了優化的數據引擎，採用列存儲，有良好的數據壓縮，處理幾百GB的數據基本上不是問題。
使用數據庫的好處之一就是，偉大的SQL可以幫我們很簡單的完成絕大部分的統計分析工作——PV只需要SELECT+COUNT，計算搜索詞排行只需要SELECT+COUNT+GROUP+ORDER+LIMIT。此外，數據庫本身的結構化存儲模式也讓日誌數據的管理變的更簡單，減少運維代價。
同樣還是上面的那個例子，簡單的一個SQL就可以搞定：
SELECT * FROM (SELECT ip, COUNT(*) AS ip_count FROM apache_log GROUP BY ip) a ORDER BY ip_count DESC LIMIT 100
至於性能問題，數據庫的索引和各種優化機制通常會讓我們的統計分析工作變得更快，並且上面提到的Infobright和Infinidb都專門爲類似SUM、COUNt之類的聚集應用做了優化。當然也不是絕對的會快，例如在數據庫中進行LIKE操作，通常會比grep一個文件還要慢很多。
更進一步的，使用基於數據庫的存儲，可以很容易的進行OLAP（聯機分析處理）應用，從日誌中挖掘價值會變的更加簡單。
更多的數據怎麼辦
一個好的數據庫似乎會讓事情變的很簡單，但是別忘了前面提到的都是單機數據庫。一臺單機在存儲容量、併發性上毫無疑問都是有很大限制的。而日誌數據的特點之一就是隨時間持續增長，並且由於很多分析過程往往需要歷史數據。短時間內的增長也許可以通過分庫、分表或者數據壓縮等來解決，不過很顯然並不是長久之計。
想要徹底解決數據規模增長帶來的問題，很自然的會想到使用分佈式技術，結合上面的結論，也許使用某個分佈式數據庫是一個好選擇，那麼對最終用戶就可以完全透明瞭。這個的確是很理想的情況，不過現實往往是殘酷的。
首先，實現比較完美的分佈式數據庫（受限於CAP原則）是一個非常複雜的問題，因此在這裏並不像單機數據庫那樣，有那麼多開源的好東西可以用，甚至於商用的也並不是太多。當然，也並非絕對，如果有錢，還是可以考慮一下Oracle RAC、Greenplum之類東西。
其次，絕大多數分佈式數據庫都是NoSQL的，所以想繼續用上SQL的那些優點基本上是沒指望，取而代之的都是一些簡單、難以使用的接口。單從這點看來，使用這些數據庫的價值已經降低很多了。
所以，還是先現實一點，先退一步考慮如何解決的超大規模的日誌的分析問題，而不是想如何讓它變的像在小數據規模時那樣簡單。單單想做到這點，目前看來並不是太難，並且依然有免費的午餐可以吃。
Hadoop是偉大的Apache基金會下面的一套分佈式系統，包括分佈式文件系統（HDFS）、MapReduce計算框架、HBase等很多組件——這些基本都是Google的GFS/MapReduce/BigTable的克隆產品。
Hadoop經過數年的發展，目前已經很成熟了，尤其是其中的HDFS和MapReduce計算框架組件。數百臺機器的集羣已經被證明可以使用，可以承擔PB級別的數據。
Hadoop項目中的HBase是一個按列存儲的NoSQL分佈式數據庫，它提供的功能和接口都非常簡單，只能進行簡單的K-V查詢，因此並不直接適用於大多數日誌分析應用。所以一般使用Hadoop來做日誌分析，首先還是需要將日誌存儲在HDFS中，然後再使用它提供的MapReduce API編寫日誌分析程序。
MapReduce是一種分佈式編程模型，並不難學習，但是很顯然使用它來處理日誌的代價依然遠大於單機腳本或者SQL。一個簡單的詞頻統計計算可能都需要上百代碼——SQL只需要一行，另外還有複雜的環境準備和啓動腳本。
例如同樣還是上面的例子，實現就要複雜的多，通常需要兩輪MapReduce來完成。首先要在第一輪的mapper中計算部分ip的訪問次數之和，並以ip爲key輸出：
//遍歷輸入，並聚合結果
foreach(record in input) {
ip = record.ip;
dict[ip]++;
}
//用emit輸出，第一個參數爲key，用於reduce的分發
foreach(<ip, count> in dict) {
emit(ip, count);
}
然後在第一輪的reduce中就可以得到每個ip完整的計數，可以順便排個序，並且只保留前100個。
count = 0;
//對於每個key（ip）,遍歷所有的values（count），並累加
while(input.values.hasNext()) {
count += input.values.next();
}
//插入到大小爲100的堆中
heap_insert(input.key, count);
在reduce結束的時候輸出：
//輸出當前reduce中count最高的100個ip
foreach(<ip, count> in dict) {
emit(ip, count);
}
由於reduce一般會有很多個，所以最後還需要將所有reduce的輸出進行合併、再排序，並得到最終的前100個IP以及對應的訪問量。
所以，使用Hadoop來做日誌分析很顯然不是一件簡單事情，它帶來了很多的額外的學習和運維成本，但是至少，它讓超大規模的日誌分析變成了可能。
怎樣變得更簡單
在超大規模的數據上做任何事情都不是一件容易的事情，包括日誌分析，但也並不是說分佈式的日誌分析就一定要去寫MapReduce代碼，總是可以去做進一步的抽象，在特定的應用下讓事情變得更簡單。
也許有人會很自然的想到如果能用SQL來操作Hadoop上的數據該有多好。事實上，不僅僅只有你一個人會這麼想，很多人都這麼想，並且他們實現了這個想法，於是就有了Hive。
Hive現在也是Hadoop項目下面的一個子項目，它可以讓我們用SQL的接口來執行MapReduce，甚至提供了JDBC和ODBC的接口。有了這個之後，Hadoop基本上被包裝成一個數據庫。當然實際上Hive的SQL最終還是被翻譯成了MapReduce代碼來執行，因此即使最簡單的SQL可能也要執行好幾十秒。幸好在通常的離線日誌分析中，這個時間還是可以接受的。更重要的是，對於上面提到的例子，我們又可以用一樣的SQL來完成分析任務了。
當然Hive並不是完全的兼容SQL語法，而且也不能做到完全的對用戶屏蔽細節。很多時候爲了執行性能的優化，依然需要用戶去了解一些MapReduce的基本知識，根據自己的應用模式來設置一些參數，否則我們可能會發現一個查詢執行很慢，或者壓根執行不出來。
另外，很顯然Hive也並不能覆蓋所有的需求，所以它依然保留插入原始MapReduce代碼的接口，以便擴展。
更多的問題
即使有了Hive這樣一個類似於數據庫的東西，我們依然還有很多事情需要做。例如時間久了，可能會有越來越多的需要例行執行的SQL，而這些SQL中，也許有一些是做了重複的事情；也許有一些的執行效率非常低下，一個複雜的SQL就佔滿了所有的計算資源。這樣的系統會變得越來越難以維護的，直到有一天例行的SQL終於跑不完了。而最終用戶往往不會去關心這些事情，他們只關心自己提交的查詢是不是能即時得到響應，怎麼樣才能儘快的拿到結果。
舉個簡單的例子，如果發現在使用apache_log的所有查詢中，幾乎沒有人用其中的user_agent字段，那麼我們完全可以把這個字段去除掉，或者拆分成兩張表，以減少多數查詢的IO時間，提高執行的效率。
爲了系統化的解決這些問題，我們可能需要引入例行任務的調度機制，可能需要去分析所有的SQL來發現哪些是可以合併的、哪些的性能需要優化，使用的數據表是不是需要做水平或者垂直分表等等。根據實際情況的不同，這時事情可能是人工來完成，也可能是寫程序來自動分析並調整。
再者隨着日誌類型、分析需求的不斷增長。用戶會越來越多的抱怨很難找到想要的數據在哪份日誌裏，或者跑的好好的查詢因爲日誌格式的變化而突然不能用了。另外上面提到的ETL過程也會變得複雜，簡單的轉換導入腳本很可能已經解決不了問題。這時候可能需要構建一個數據管理系統，或者乾脆考慮建立一個所謂的數據倉庫。
總之，隨着日誌數據量、日誌類型、用戶數量、分析需求等等的不斷增長，越來越多的問題會逐漸浮現出來，日誌分析這件事情可能就不再像我們最初想的那麼簡單，會變得越來越有價值，也越來越有挑戰。
Web日誌挖掘分析的方法
日誌文件的格式及其包含的信息
①2006-10-17 00:00:00②202.200.44.43 ③218.77.130.24 80 ④GET ⑤/favicon.ico
⑥Mozilla/5.0+(Windows；+U；+Windows+NT+5.1；+zh-CN；+rv：1.8.0.3)+Gecko/20060426
+Firefox/1.5.0.3。
①訪問時間；②用戶IP地址；③訪問的URL，端口；④請求方法(“GET”、“POST”等)；
⑤訪問模式；⑥agent，即用戶使用的操作系統類型和瀏覽器軟件。
一、日誌的簡單分析
1、注意那些被頻繁訪問的資源
2、注意那些你網站上不存在資源的請求。常見的掃描式攻擊還包括傳遞惡意參數等：
3、觀察搜索引擎蜘蛛的來訪情況
4、觀察訪客行爲
應敵之策：
1、封殺某個IP
2、封殺某個瀏覽器類型（Agent）
3、封殺某個來源（Referer）
4、防盜鏈
5、文件重命名
作用：
1.對訪問時間進行統計，可以得到服務器在某些時間段的訪問情況。
2.對IP進行統計，可以得到用戶的分佈情況。
3.對請求URL的統計，可以得到網站頁面關注情況。
4.對錯誤請求的統計，可以更正有問題的頁面。
二、Web挖掘
根據所挖掘的Web 數據的類型，可以將Web 數據挖掘分爲以下三類：Web 內容挖掘(Web Content Mining)、Web 結構挖掘(Web Structure Mining)、Web 使用挖掘(Web Usage Mining)（也稱爲Web日誌挖掘）。
①Web內容挖掘。Web內容挖掘是指從文檔的內容中提取知識。Web內容挖掘又分爲文本挖掘和多媒體挖掘。目前多媒體數據的挖掘研究還處於探索階段,Web文本挖掘已經有了比較實用的功能。Web文本挖掘可以對Web上大量文檔集合的內容進行總結、分類、聚類、關聯分析,以及利用Web文檔進行趨勢預測等。Web文檔中的標記,例如<Title>和<Heading>等蘊含了額外的信息,可以利用這些信息來加強Web文本挖掘的作用。
②Web結構挖掘。Web結構挖掘是從Web的組織結構和鏈接關係中推導知識。它不僅僅侷限於文檔之間的超鏈接結構,還包括文檔內部的結構。文檔中的URL目錄路徑的結構等。Web結構挖掘能夠利用網頁間的超鏈接信息對搜索引擎的檢索結果進行相關度排序,尋找個人主頁和相似網頁,提高Web搜索蜘蛛在網上的爬行效率,沿着超鏈接優先爬行。Web結構挖掘還可以用於對Web頁進行分類、預測用戶的Web鏈接使用及Web鏈接屬性的可視化。對各個商業搜索引擎索引用的頁數量進行統計分析等。
③Web使用記錄挖掘。Web使用記錄挖掘是指從Web的使用記錄中提取感興趣的模式，目前Web使用記錄挖掘方面的研究較多,WWW中的每個服務器都保留了訪問日誌,記錄了關於用戶訪問和交互的信息,可以通過分析和研究Web日誌記錄中的規律,來識別網站的潛在用戶;可以用基於擴展有向樹模型來識別用戶瀏覽序列模式,從而進行Web日誌挖掘;可以根據用戶訪問的Web記錄挖掘用戶的興趣關聯規則,存放在興趣關聯知識庫中,作爲對用戶行爲進行預測的依據,從而爲用戶預取一些Web頁面,加快用戶獲取頁面的速度，分析這些數據還可以幫助理解用戶的行爲,從而改進站點的結構,或爲用戶提供個性化的服務。
通過對Web服務器日誌中大量的用戶訪問記錄深入分析，發現用戶的訪問模式和興趣愛好等有趣、新穎、潛在有用的以及可理解的未知信息和知識，用於分析站點的使用情況，從而輔助管理和支持決策。當前，web日誌挖掘主要被用於個性化服務與定製、改進系統性能和結構、站點修改、商業智能以及web特徵描述等諸多領域。
三、Web日誌挖掘的方法
（一）首先，進行數據的預處理。
從學習者的訪問日誌中得到的原始日誌記錄並不適於挖掘，必須進行適當的處理才能進行挖掘。因此，需要通過日誌清理，去除無用的記錄；對於某些記錄，我們還需要通過站點結構信息，把URL路徑補充成完整的訪問序列；然後劃分學習者，並把學習者的會話劃分成多個事務。
（二）其次，進行模式發現
一旦學習者會話和事務識別完成，就可以採用下面的技術進行模式發現。模式發現, 是對預處理後的數據用數據挖掘算法來分析數據。分有統計、分類、聚類、關等多種方法。
① 路徑分析。它可以被用於判定在一個站點中最頻繁訪問的路徑，還有一些其它的有關路徑的信息通過路徑分析可以得出。路徑分析可以用來確定網站上的頻繁訪問路徑, 從而調整和優化網站結構, 使得用戶訪問所需網頁更加簡單快捷, 還可以根據用戶典型的瀏覽模式用於智能推薦和有針對性的電子商務活動。例如：70% 的學習者在訪問/ E-Business /M2時，是從/EB開始，經過/ E-Business /SimpleDescription，/ E-Business /M1；65%的學習者在瀏覽4個或更少的頁面內容後就離開了。利用這些信息就可以改進站點的設計結構。
② 關聯規則。 使用關聯規則發現方法，可以從Web的訪問事務中找到的相關性。關聯規則是尋找在同一個事件中出現的不同項的相關性，用數學模型來描述關聯規則發現的問題：x=>y的蘊含式，其中x,y爲屬性——值對集(或稱爲項目集)，且X∩Y空集。在數據庫中若S%的包含屬性——值對集X的事務也包含屬性——值集Y，則關聯規則X=>Y的置信度爲C%。
③ 序列模式。在時間戳有序的事務集中，序列模式的發現就是指那些如“一些項跟隨另一個項”這樣的內部事務模式。它能發現數據庫中如“在某一段時間內，客戶購買商品A，接着會購買商品B，爾後又購買商品C，即序列A→B→C出現的頻率高”之類的信息。序列模式描述的問題是：在給定的交易序列數據庫中，每個序列按照交易的時間排列的一組交易集，挖掘序列函數作用是返回該數據庫中高頻率出現有序列。
④ 分類分析。發現分類規則可以給出識別一個特殊羣體的公共屬性的描述，這種描述可以用於分類學習者。分類包括的挖掘技術將找出定義了一個項或事件是否屬於數據中某特定子集或類的規則。該類技術是最廣泛應用於各類業務問題的一類挖掘技術。分類算法最知名的是決策樹方法，此外還有神經元網絡、Bayesian分類等。例如：在/ E-Business /M4學習過的學習者中有40％是20左右的女大學生。
⑤聚類分析。可以從Web訪問信息數據中聚類出具有相似特性的學習者。在Web事務日誌中，聚類學習者信息或數據項能夠便於開發和設計未來的教學模式和學習羣體。聚類是將數據集劃分爲多個類，使得在同一類中的數據之間有較高的相似度，而在不同類中的數據差別儘可能大。在聚類技術中，沒有預先定義好的類別和訓練樣本存在，所有記錄都根據彼此相似程度來加以歸類。主要算法有k—means、DBSCAN等。聚類分析是把具有相似特徵的用戶或數據項歸類,在網站管理中通過聚類具有相似瀏覽行爲的用戶。基於模糊理論的Web頁面聚類算法與客戶羣體聚類算法的模糊聚類定義相同，客戶訪問情況可用URL(Uj)表示。有Suj={(Ci，fSuj(Ci))|Ci∈C}，其中fSuj(Ci)→[0，1]是客戶Ci和URL(Uj)間的關聯度：式中m爲客戶的數量，hits(Ci)表示客戶Ci訪問URL(Uj)的次數。利用Suj和模糊理論中的相似度度量Sfij定義建立模糊相似矩陣，再根據相似類[Xi]R的定義構造相似類，合併相似類中的公共元素得到的等價類即爲相關Web頁面。
⑥統計。統計方法是從Web 站點中抽取知識的最常用方法, 它通過分析會話文件, 對瀏覽時間、瀏覽路徑等進行頻度、平均值等統計分析。雖然缺乏深度, 但仍可用於改進網站結構, 增強系統安全性, 提高網站訪問的效率等。
⑦協同過濾。協同過濾技術採用最近鄰技術，利用客戶的歷史、喜好信息計算用戶之間的距離，目標客戶對特點商品的喜好程度由最近鄰居對商品的評價的加權平均值來計算。
（三）最後，進行模式分析。
模式分析。基於以上的所有過程，對原始數據進行進一步分析，找出用戶的瀏覽模式規律，即用戶的興趣愛好及習慣，並使其可視化，爲網頁的規劃及網站建設的決策提供具體理論依據。其主要方法有：採用SQL查詢語句進行分析；將數據導入多維數據立方體中，用OLAP工具進行分析並給出可視化的結果輸出。（分類模式挖掘、聚類模式挖掘、時間序列模式挖掘、序列模式挖掘、關聯規則等）
四、關聯規則
（一）關聯規則
顧名思義，關聯規則（association rule）挖掘技術用於於發現數據庫中屬性之間的有趣聯繫。一般使用支持度（support）和置信度（confidence）兩個參數來描述關聯規則的屬性。
（二）Apriori方法簡介
Apriori算法最先是由Agrawal等人於1993年提出的，它的基本思想是：首先找出所有具有超出最小支持度的支持度項集，用頻繁的(k—1)-項集生成候選的頻繁k-項集；其次利用大項集產生所需的規則；任何頻繁項集的所有子集一定是頻繁項集是其核心。
Apriori算法需要兩個步驟：第一個是生成條目集；第二個是使用生成的條目集創建一組關聯規則。當我們把最小置信度設爲85%，通過關聯規則的形成以及對應置信度的計算，我們可以從中得到以下有用的信息：
1.置信度大於最小置信度時：我們可以這樣認爲，用戶羣體在瀏覽相關網頁時，所呈列的鏈接之間是有很大關聯的，他們是用戶羣的共同愛好，通過網頁佈局的調整，從某種意義上，可以帶來更高的點擊率及潛在客戶；
2.置信度小於最小置信度時：我們可以這樣認爲，用戶羣體對所呈列鏈接之間沒太多的關聯，亦或關聯規則中的鏈接在爭奪用戶。
五、網站中Web日誌挖掘內容
（1）網站的概要統計。網站的概要統計包括分析覆蓋的時間、總的頁面數、訪問數、會話數、惟一訪問者、以及平均訪問、最高訪問、上週訪問、昨日訪問等結果集。
（2）內容訪問分析。內容訪問分析包括最多及最少被訪問的頁面、最多訪問路徑、最多訪問的新聞、最高訪問的時間等。
（3）客戶信息分析。客戶信息分析包括訪問者的來源省份統計、訪問者使用的瀏覽器及操作系統分析、訪問來自的頁面或者網站、來自的IP地址以及訪問者使用的搜索引擎。
（4）訪問者活動週期行爲分析。訪問者活動週期行爲分析包括一週7天的訪問行爲、一天24小時的訪問行爲、每週的最多的訪問日、每天的最多訪問時段等。
（5）主要訪問錯誤分析。主要訪問錯誤分析包括服務端錯誤、頁面找不到錯誤等。
（6）網站欄目分析。網站欄目分析包括定製的頻道和欄目設定，統計出各個欄目的訪問情況，並進行分析。
（7）商務網站擴展分析。商務網站擴展分析是專門針對專題或多媒體文件或下載等內容的訪問分析。
（8）有4個方向可以選擇:①對用戶點擊行爲的追蹤，click stream研究；②對網頁之間的關聯規則的研究；③對網站中各個頻道的瀏覽模式的研究；④根據用戶瀏覽行爲，對用戶進行聚類，細分研究；（如果你能夠結合現有的互聯網產品和應用提出一些自己的建議和意見，那就更有價值了。）
（9）發現用戶訪問模式。通過分析和探究Web日誌記錄中的規律，可以識別電子商務的潛在客戶，提高對最終用戶的服務質量，並改進Web服務器系統的性能。
(10)反競爭情報活動。反競爭情報是企業競爭情報活動的重要組成部分。
六、相關軟件及算法
（一）相關軟件：
1.數據挖掘的專用軟件wake。
2.用OLAP工具
3.已經有部分公司開發出了商用的網站用戶訪問分析系統，如WebTrends公司的CommerceTrends 3.0,它能夠讓電子商務網站更好地理解其網站訪問者的行爲，幫助網站採取一些行動來將這些訪問者變爲顧客。CommerceTrends主要由3部分組成：Report Generation Server、Campain Analyzer和Webhouse Builder。
4.Accrue公司的Accrue Insight，它是一個綜合性的Web分析工具,它能夠對網站的運行狀況有個深入、細緻和準確的分析，通過分析顧客的行爲模式，幫助網站採取措施來提高顧客對於網站的忠誠度，從而建立長期的顧客關係。
（二）相關算法：
1.運用各種算法進行數據挖掘：GSP算法, Prefixspana算法，
2.關聯規則分析：Apriori、FP-growth算法等。
3.Apriori算法及其變種算法
4.基於數據庫投影的序列模式生長技術（database project based sequential pattern growth）
5. Wake算法、MLC++等
6. PageRank算法和HITS算法利用Web頁面間的超鏈接信息計算“權威型”（Authorities）網頁和“目錄型”（Hubs）網頁的權值。Web結構挖掘通常需要整個Web的全局數據，因此在個性化搜索引擎或主題搜索引擎研究領域得到了廣泛的應用。
7.參考檢索引擎的挖掘算法，比如Apache的lucene等。
七、日誌分析的價值或應用
①在自己的網站上安裝了網站統計的代碼，如Google analytics、量子統計、百度統計、cnzz、51.la等，這些工具可以統計網站的流量，也就是網站上訪客可看到的所有頁面的訪問量，但是這些統計工具都不能統計你主機上資源的原始訪問信息，例如某個圖片被誰下載了。
②如果你的網站遭到了攻擊、非法盜鏈和不良請求等，通過分析原始訪問日誌能大概分析出端倪來，例如：往主機上傳了一個mp3，不幸被百度mp3收錄，引來大量的盜鏈，導致我的主機流量猛增！通過分析日誌，可以找出問題根源，刪除了那個mp3，主機流量也降下來了。
③分析訪客來源（Referer）。這一段是告訴我們訪客是從哪裏來到這一個網頁。有可能是網站其他頁，有可能是來自搜索引擎的搜索頁等。通過這條來源信息，你可以揪出盜鏈者的網頁。
④網站日誌分析軟件都能提供關於服務器的瀏覽量、統計網站所有頁面和相關文件被顯示的次數、訪問最多的網頁、客戶端訪問最頻繁的文件、訪問者的IP分佈、每日訪問統計、每週每月等的統計結果。1.訪問者訪問時段分析。結合IP地址和時段之間的關係可以將來訪者大致的身份作一個基本的判斷。如按上班前、工作期間、下班後、節假日等，可以針對訪客的初步性質安排合適的內容，如產品信息和廣告；2.訪問者地區分佈。分析通過將訪問者的IP地址轉換爲地理區間可以分析出來訪者的大致地理分佈範圍。
⑤相關產品推薦。通過以上的關聯分析，有了用戶頻繁訪問路徑和鏈接之間的興趣度，可以構建個性化推薦系統模型。對於實證例子，我們可以在置信度高於最低置信度的相關鏈接之間，建立某種信息快速互聯的橋樑，亦或是在網頁規劃中，充分考慮鏈接之間的關聯關係，從而爲更人性化、合理化的網頁設計提供決策依據。如：當客戶瀏覽/newimg/num1.gif時，有0.91的概率會瀏覽/newimg/num4.gif，那麼，在兩者之間就存在很高的關聯性，從而我們有必要對這兩個鏈接建立某種跟緊密的聯繫。
⑥個性挖掘：針對單個用戶的使用記錄對該用戶進行建模，結合該用戶基本信息分析他的使用習慣、個人喜好，目的是在電子商務環境下爲該用戶提供與衆不同的個性化服務。
⑦系統改進：Web服務（數據庫、網絡等）的性能和其他服務質量是衡量用戶滿意度的關鍵指標，Web 用法挖掘可以通過用戶的擁塞記錄發現站點的性能瓶頸，以提示站點管理者改進Web緩存策略、網絡傳輸策略、流量負載平衡機制和數據的分佈策略。此外，可以通過分析網絡的非法入侵數據找到系統弱點，提高站點安全性，這在電子商務環境下尤爲重要。
⑧站點修改：站點的結構和內容是吸引用戶的關鍵。Web 用法挖掘通過挖掘用戶的行爲記錄和反饋情況爲站點設計者提供改進的依，比如頁面連接情況應如何組織、那些頁面應能夠直接訪問等。
⑨智能商務：用戶怎樣使用Web站點的信息無疑是電子商務銷售商關心的重點，用戶一次訪問的週期可分爲被吸引、駐留、購買和離開四個步驟，Web用法挖掘可以通過分析用戶點擊流等Web日誌信息挖掘用戶行爲的動機，以幫助銷售商合理安排銷售策略。
⑩Web特徵描述：這類研究跟關注這樣通過用戶對站點的訪問情況統計各個用戶在頁面上的交互情況，對用戶訪問情況進行特徵描述。