整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
集web日志的目的
Web日志挖掘是指采用數據挖掘技術，對站點用戶訪問Web服務器過程中產生的日志數據進行分析處理，從而發現Web用戶的訪問模式和興趣愛好等，這些信息對站點建設潛在有用的可理解的未知信息和知識，用于分析站點的被訪問情況，輔助站點管理和決策支持等。
1、以改進web站點設計為目標，通過挖掘用戶聚類和用戶的頻繁訪問路徑，修改站點的頁面之間的鏈接關系，以適應用戶的訪問習慣，并且同時為用戶提供有針對性的電子商務活動和個性化的信息服務，應用信息推拉技術構建智能化Web站點。
2、以分析Web站點性能為目標，主要從統計學的角度，對日志數據項進行粗略的統計分析，得到用戶頻繁訪問頁、單位時間的訪問數、訪問數量隨時間分布圖等。現有的絕大多數的Web日志分析工具都屬于此類。
3、以理解用戶意圖為目標，主要是通過與用戶交互的過程收集用戶的信息，Web服務器根據這些信息對用戶請求的頁面進行裁剪，為用戶返回定制的頁面，其目的就是提高用戶的滿意度和提供個性化的服務。
收集方式
網站分析數據主要有三種收集方式：Web日志、JavaScript標記和包嗅探器。
1. Web日志
web日志處理流程：
從上圖可以看出網站分析數據的收集從網站訪問者輸入URL向網站服務器發出http請求就開始了。網站服務器接收到請求后會在自己的Log文件中追加一條記錄，記錄內容包括：遠程主機名(或者是IP地址)、登錄名、登錄全名、發請求的日期、發請求的時間、請求的詳細(包括請求的方法、地址、協議)、請求返回的狀態、請求文檔的大小。隨后網站服務器將頁面返回到訪問者的瀏覽器內得以展現。
2. JavaScript標記
JavaScript標記處理流程：
上圖所示JavaScript標記同Web日志收集數據一樣，從網站訪問者發出http請求開始。不同的是，JavaScript標記返回給訪問者的網頁代碼中會包含一段特殊的JavaScript代碼，當頁面展示的同時這段代碼也得以執行。這段代碼會從訪問者的Cookie中取得詳細信息(訪問時間、瀏覽器信息、工具廠商賦予當前訪問者的userID等)并發送到工具商的數據收集服務器。數據收集服務器對收集到的數據處理后存入數據庫中。網站經營人員通過訪問分析報表系統查看這些數據。
3. 包嗅探器
通過包嗅探器收集分析的流程：
上圖可以看出網站訪問者發出的請求到達網站服務器之前，會先經過包嗅探器，然后包嗅探器才會將請求發送到網站服務器。包嗅探器收集到的數據經過工具廠商的處理服務器后存入數據庫。隨后網站經營人員就可以通過分析報表系統看到這些數據。
web日志挖掘過程
整體流程參考下圖：
1、數據預處理階段根據挖掘的目的，對原始Web日志文件中的數據進行提取、分解、合并、最后轉換為用戶會話文件。該階段是Web訪問信息挖掘最關鍵的階段，數據預處理包括:關于用戶訪問信息的預處理、關于內容和結構的預處理。
2、會話識別階段該階段本是屬于數據預處理階段中的一部分，這里將其劃分成單獨的一個階段，是因為把用戶會話文件劃分成的一組組用戶會話序列將直接用于挖掘算法，它的精準度直接決定了挖掘結果的好壞，是挖掘過程中最重要的階段。
3、模式發現階段模式發現是運用各種方法和技術從Web日志數據中挖掘和發現用戶使用Web的各種潛在的規律和模式。模式發現使用的算法和方法不僅僅來自數據挖掘領域，還包括機器學習、統計學和模式識別等其他專業領域。
模式發現的主要技術有：統計分析（statistical analysis）、關聯規則（association rules）、聚類（clustering）、歸類（classification）、序列模式（sequential patterns）、依賴關系（dependency）。
（1）統計分析（statistical analysis）：常用的統計技術有：貝葉斯定理、預測回歸、對數回歸、對數-線性回歸等。可用來分析網頁的訪問頻率，網頁的訪問時間、訪問路徑。可用于系統性能分析、發現安全漏洞、為網站修改、市場決策提供支持。
（2）關聯規則（association rules）：關聯規則是最基本的挖掘技術，同時也是WUM最常用的方法。在WUM中常常用在被訪問的網頁中，這有利于優化網站組織、網站設計者、網站內容管理者和市場分析，通過市場分析可以知道哪些商品被頻繁購買，哪些顧客是潛在顧客。
（3）聚類（clustering）：聚類技術是在海量數據中尋找彼此相似對象組，這些數據基于距離函數求出對象組之間的相似度。在WUM中可以把具有相似模式的用戶分成組，可以用于電子商務中市場分片和為用戶提供個性化服務。
（4）歸類（classification）：歸類技術主要用途是將用戶資料歸入某一特定類中，它與機器學習關系很緊密。可以用的技術有：決策樹（decision tree）、K-最近鄰居、Na?ve Bayesian classifiers、支持向量機（support vector machines）。
（5）序列模式（sequential patterns）：給定一個由不同序列組成的集合，其中，每個序列由不同的元素按順序有序排列，每個元素由不同項目組成，同時給定一個用戶指定的最小支持度閾值，序列模式挖掘就是找出所有的頻繁子序列，即子序列在序列集中的出現頻率不低于用戶指定的最小支持度閾值。
（6）依賴關系（dependency）：一個依賴關系存在于兩個元素之間，如果一個元素A的值可以推出另一個元素B的值，則B依賴于A。
4、模式分析階段模式分析是Web使用挖掘最后一步，主要目的是過濾模式發現階段產生的規則和模式，去除那些無用的模式，并把發現的模式通過一定的方法直觀的表現出來。由于Web使用挖掘在大多數情況下屬于無偏向學習，有可能挖掘出所有的模式和規則，所以不能排除其中有些模式是常識性的，普通的或最終用戶不感興趣的，故必須采用模式分析的方法使得挖掘出來的規則和知識具有可讀性和最終可理解性。常見的模式分析方法有圖形和可視化技術、數據庫查詢機制、數理統計和可用性分析等。
收集數據包括
收集的數據主要包括：
全局UUID、訪問日期、訪問時間、生成日志項的服務器的IP地址、客戶端試圖執行的操作、客戶端訪問的服務器資源、客戶端嘗試執行的查詢、客戶端連接到的端口號、訪問服務器的已驗證用戶名稱、發送服務器資源請求的客戶端IP地址、客戶端使用的操作系統、瀏覽器等信息、操作的狀態碼（200等）、子狀態、用Windows@使用的術語表示的操作的狀態、點擊次數。
用戶識別
對于網站的運營者來說，如何能夠高效精確的識別用戶非常關鍵，這會對網站運營帶來極大的幫助，如定向推薦等。
用戶識別方法如下：
使用HDFS存儲
數據收集到服務器之后，根據數據量可以考慮將數據存儲在hadoop的HDFS中。
在現在的企業中，一般情況下都是多臺服務器生成日志，日志包括nginx生成的，也包括在程序中使用log4j生成的自定義格式的。
通常的架構如下圖：
使用mapreduce分析nginx日志
nginx默認的日志格式如下：
222.68.172.190--[18/Sep/2013:06:49:57+0000]"GET/images/my.jpgHTTP/1.1"20019939
remote_addr: 記錄客戶端的ip地址, 222.68.172.190
remote_user: 記錄客戶端用戶名稱, –
time_local: 記錄訪問時間與時區, [18/Sep/2013:06:49:57 +0000]
request: 記錄請求的url與http協議, “GET /images/my.jpg HTTP/1.1″
status: 記錄請求狀態,成功是200, 200
body_bytes_sent: 記錄發送給客戶端文件主體內容大小, 19939
http_referer: 用來記錄從那個頁面鏈接訪問過來的, “http://www.angularjs.cn/A00n”
http_user_agent: 記錄客戶瀏覽器的相關信息, “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36″
可以直接使用mapreduce來進行日志分析：
在hadoop中計算后定時導入到關系型數據庫中進行展現。
也可以使用hive來代替mapreduce進行分析。
總結
web日志收集是每個互聯網企業必須要處理的過程，當收集上來數據，并且通過適當的數據挖掘之后，會對整體網站的運營能力及網站的優化帶來質的提升，真正的做到數據化分析和數據化運營。
via：cloudsky
End.
對于一個系統來說，監控、鏈路追蹤、日志的這三者需求都是必然存在的，而有的時候我們會搞不清楚這三者相互之間是什么關系。我之前在做系統設計的時候也考慮過，是不是有必要引入那么多組件，畢竟如果這三者完全分開每一個一項的話，就有三個組件了（事實上就是：Prometheus+Grafana、Jaeger、ELK）。
因此想做個筆記嘗試舉例來梳理下。
外部鏈接：
Monitoring（監控）舉例來說就是：定期體檢。使用監控系統把需要關注的指標采集起來，形成報告，并對需要關注的異常數據進行分析形成告警。
特點是：
這也是Prometheus的架構做得非常簡單的原因，Monitoring的需求并沒有包含非常高的并發量和通訊量。反過來說：高并發、大數據量的需求并不適用于Monitoring這個點。
Tracing（鏈路追蹤）舉例來說就是：對某一項工作的定期匯報。某個工作開始做了A，制作A事件的報告，收集起來，然后這個工作還有B、C、D等條目，一個個處理，然后都匯總進報告，最終的結果就是一個Tracing。
特點是：
因為Tracing是針對某一個事件（一般來說就是一個API），而這個API可能會和很多組件進行溝通，后續的所有的組件溝通無論是內部還是外部的IO，都算作這個API調用的Tracing的一部分。可以想見在一個業務繁忙的系統中，API調用的數量已經是天文數字，而其衍生出來的Tracing記錄更是不得了的量。其特點就是高頻、巨量，一個API會衍生出大量的子調用。
也因此適合用來做Monitoring的系統就不一定適合做Tracing了，用Prometheus這樣的系統來做Tracing肯定完蛋（Prometheus只有拉模式，全部都是HTTP請求，高并發直接掛掉）。一般來說Tracing系統都會在本地磁盤IO上做日志（最高效、也是最低的Cost），然后再通過本地Agent慢慢把文本日志數據發送到聚合服務器上，甚至可能在聚合服務器和本地的Agent之間還需要做消息隊列，讓聚合服務器慢慢消化巨量的消息。
Tracing在現在的業界是有標準的：OpenTracing，因此它不是很隨意的日志/事件聚合，而是有格式要求的日志/事件聚合，這就是Tracing和Logging最大的不同。
Logging（日志）舉例來說就是：廢品回收站。各種各樣的物品都會匯總進入到配品回收站里，然后經過分門別類歸納整理，成為各種可回收資源分別回收到商家那里。一般來說我們在大型系統中提到Logging說的都不是簡單的日志，而是日志聚合系統。
從本質上來說，Monitoring和Tracing都是Logging，Logging是這三者中覆蓋面最大的超集，而前兩者則是其一部分的子集。Logging最麻煩的是，開發者也不會完全知道最后記錄進入到日志系統里的一共會有哪些東西，只有在使用（檢索）的時候才可能需要匯總查詢總量中的一部分。
要在一般的Loggin系統中進行Monitoring也是可以的，直接把聚合進來的日志數據提取出來，定期形成數據報告，就是監控了。Tracing也是一樣，只要聚合進了Logging系統，有了原始數據，后面要做都是可以做的。因此Logging系統最為通用，其特點和Tracing基本一致，也是需要處理高頻并發和巨大的數據量。
這樣一看就很清楚了，每個組件都有其存在的必要性：
日志是我們運維用來分析問題和處理問題的重要維護依據，但是Nginx的日志文件是非常龐大的，而且以文本格式顯示導致Nginx的日志直接分析非常困難。有時候為了初步處理或緊急處理問題，我們也對直接打開Nginx的日志文件進行分析，這里我們就介紹如何對Nginx的默認日志格式進行分析和含義的解讀。
在安裝好Nginx后系統會默認給你開通access.log訪問日志功能，這個配置文件在etc/nginx的文件夾下，打開配置文件后如下面是按行進行的默認格式配置。
log_format main ' $remote_addr - $remote_user [$time_local] "$request" '' $status $body_bytes_sent " $http_referer" '' "$http_user_agent" "$http_x_forwarded_for" ';
Nginx日志的配置項目：access_log /var/log/nginx/access.log main;
日志寫入文本文件是一行行的，這里我們把一行日志，按3個字段進行分行進行分析。
61.135.165.19 - 這里是訪問者的IP地址
- 這里是客戶名稱，但一般獲取不到。
[17/Nov/2018:03:39:32 +0800] 這里是訪問的時間
"GET /ask/0901/images/a13.jpg HTTP/1.0" 這個是這次記錄的訪問對象
200 返回的狀態碼
19916 這條記錄訪問對象的大小
"http://xx.xx.xx/ask/0901/index.htm?jh=haerbinlvyou-YD&gjc=7riyoudongbei&e_keywordid=%7Bkeywordid%7D" 這個是從什么入口訪問的也就是來源。
"Mozilla/5.0 (Linux; U; Android 4.1; en-us; GT-N7100 Build/JRO03C;Baiduspider-ads)AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30" 這個是客戶端瀏覽器的一些參數
"10.205.160.32" 這里是代理的地址，一般是沒有的。
remote_addr 遠程請求IP地址
remote_user 客戶端用戶的名稱,沒有時用-符合代替
time_local 本地時間戳
request 請求具體URI文件，例如網頁中的JPG圖片。
status http請求狀態
body_bytes_sent 請求文件大小
http_refer 網頁url跳轉來源，源地址，可以偽造。例如一個HTML網頁然后調用圖片URI資源。
http_user_agent 用戶終端瀏覽器UserAgent的相關信息
http_x_forwarded_for是HTTP的請求端真實的IP,只有在通過了HTTP 代理或者負載均衡服務器時才會添加該項
其他非默認的選項
host 請求host地址
request_time 整個請求的總時間
upstream_addr 后臺提供服務的地址(即轉發處理的目標地址)
upstream_reponse_time請求時，upstream的響應時間
upstream_status upstream狀態
通過如下方式達到日志切割：
# vi logcron.sh
log_dir="/data/logs/nginx"
date_dir=`date +%Y%m%d`
/bin/mkdir -p ${log_dir}/${date_dir} > /dev/null 2>&1
/bin/mv ${log_dir}/access.log ${log_dir}/${date_dir}/access.log
這里只需要定義一個cron，在每天晚上23:59:50執行這個腳本就可以了。
篇幅有限，關于nginx的access.log訪問日志方面就介紹到這了，后面會分享更多關于devops和DBA方面內容，感興趣的朋友可以關注下！
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
