需要統計的頁面都匯入js統計**，根據要統計的資訊訪問統計伺服器api位址
要統計的內容舉例：
（ip什麼的就不上報了，交給nginx）
然而真實的統計**是要做容錯處理的，比如說乙個頁面套乙個頁面的時候會不會統計兩次，要不要加全域性鎖，防止呼叫一次以後再呼叫統計多次的問題......
nginx併發效能很強勁，所以選用它
絕大多數伺服器，都不允許靜態檔案響應post請求(get請求靜態檔案是天經地義的)，否則會返回http/1.1 405 method not allowed錯誤。
然而在前端開發中，前端開發工程師經常模擬後端請求，返回靜態資料來檢視頁面效果，怎麼辦？
目前有兩種方案解決：
在nginx.conf中，請求的靜態資料路徑中，新增如下語句error_page 405=200 $request_uri：
location ~ \.(action|jsp)方案二：修改nginx原始碼編譯
找到檔案ngx_http_static_module.c，然後找到下面**並注釋掉。
if (r->method & ngx_http_post)然後按照原來的編譯引數，重新編譯安裝nginx即可。
推薦方案一，簡單方便無***，^_^。
nginx.conf中按照方案一配置：
#打點伺服器配置（url訪問dig，顯示乙個1*1畫素的gif）
location = /dig {
empty_gif;
#絕大多數伺服器，都不允許靜態檔案響應post請求（get請求靜態檔案是天經地義的），否則會返回http/1.1 405 method not allowed錯誤，然而在前端開發中，前端開發工程師經常模擬後端請求，返回靜態資料來檢視頁面效果，怎麼辦？這樣咯：
error_page 405 =200 $request_uri;
訪問localhost/dig:
(顯示乙個1*1畫素的gif)
注意：同時要開啟access_log儲存訪問記錄、日誌格式：
'"$http_user_agent" "$http_x_forwarded_for"';(日誌的格式)
access_log logs/access.log main;
以及一些nginx效能調優，可以根據機器的軟硬體配置來調整：
gzip內建字典，重複越多，壓縮越好。gzip在傳輸的內容多的時候可以開啟節省傳輸資料大小，但在傳輸少量內容的時候反而沒多少用，還浪費cpu效能。
問題：問：為什麼要用empty_gif來做接收返回響應？
答：常識是要傳送給api介面，返回json、狀態碼等。然而只要是json就是一長串的字元，在高併發的專案中，在高峰期壓力非常高，它要接收請求返回json，很難構造很小的響應。而且，打點伺服器只要上報，不要返回（完全不返回也不行，三次握手需要response），所以用empty_gif來做極小的response。
埋點日誌MySQL 資料採集之js埋點
worker processes 2 events if ngx.var.arg domain then ngx.location.capture i log?ngx.var.args utrace uid end add header expires fri,01 jan 1980 00 00 0...
日誌資料埋點 大促保障（日誌採集鏈路優化）
參考 大資料之路 阿里巴巴大資料實踐 日誌規模化採集方案的目標 1 實現與終端技術特點無關 2 高度擴充套件性 3 高度適應性 海量日誌資料的 採集 傳輸 處理 應用的過程優化 1 日誌的請求url盡可能的靠前的布置路由差異，今早的進行分流。降低日誌處理過程中分支判斷消耗，並作為後續資源調配的前提，...
Nginx日誌配置遠端Syslog採集
本文將指引你 如何對nginx日誌進行採集，並通過syslog協議，自動實時的傳送到遠端的集中日誌分析中心，便於集中式的日誌儲存和管理，提高 的運維效率。第一步 初始化日誌採集環境 先確保系統中的 var spool rsyslog 目錄已存在 mkdir v var spool rsyslog i...