Nginx的訪問日誌輪詢切割

通常什麼情況Nginx會把所有的訪問日誌生成到一個制定的訪問日誌檔案access.log裡面，但時間一長，日誌個頭很大不利於日誌的分析和處理。

有必要對Nginx日誌進行按天或按小時進行切割，分成不同的檔案儲存。

[[email protected] logs]#cat /server/script/cut_nginx_log.sh
#!/bin/sh
Dataformat = `date +%Y%m%d`
Basedir = "/usr/local/nginx"
Nginxlogdir = "$Basedir/logs"
Logname = "access_www"
[ -d $Nginxlogdir ] && cd $Nginxlogdir || exit 1
[ -f ${Logname}.log] || exit 1
/bin/mv ${Logname}.log ${Dateformat}_${Logname}.log
$Basedir/sbin/nginx -s reload

注意：指令碼實現切割Nginx日誌的思想為講正在寫入的Nginx日誌改名為（20161111_access_www.log）,然後平滑重啟生成新的nginx日誌（access_www.log）

通過定時任務實現每天的00點整定時執行/server/script/cut_nginx_log.sh

00 00 * * * /bin/sh /server/script/cut_nginx_log.sh >/dev/null 2>&1

Nginx 的location語法

location的使用基本語法：

location [= | ~ | ~* | ^~] uri {
....
}

location   指令
[
 
=|~|~*|@] 匹配標識
uri    匹配的網站網址
{。。。。}  匹配URI後要執行的配置段

~ 區分大小寫（大小寫敏感）

　~* 不區分大小寫匹配

 ！取反

 ^~ 的作用是用來進行常規的字串匹配檢查之後不做正則表示式的檢查

匹配例項

location = / {
    [ configuration A]
}

location / {
    [ configuration B]
}

location /documents/ {
    [ configuration C]
}

location ^~ /images/ {
    [ configuration D]
}
 

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E]
}

使用者請求的URL

http://www.abc.com/    匹配A    /
http://www.abc.com/    匹配B    /index.html
http://www.abc.com/documents/document.html    匹配C    /documents/document.html
http://www.abc.com/images/1.gif    匹配D    /images/1.gif
http://www.abc.com/documents/1.gif    匹配E  /documents/1.gif

Nginxd rewrite

\  進行轉義
^ 匹配輸入字串的起始位置
$ 匹配輸入字串的結束位置
* 匹配0次或多次
+ 匹配1次到多次
？ 匹配0次到1次
.   匹配除\n以外的任意字元
(pattern) 匹配括號內的字元

rewrite 指令最後一項引數flag標記說明

last　　本條規則匹配完成後，繼續向下匹配新的location URI規則
break　　本條規則匹配完成即終止，不在匹配後面的任何規則
redirect 返回302 臨時重定向， 瀏覽器位址列會顯示跳轉後的URI地址
permanent  返回301 永久重定向， 瀏覽器位址列會顯示跳轉後的URI地址

例項：

rewrite ^/(.*) http://www.abc.com/$1 permanent;

Nginx負載均衡

負載均衡模組的元件

ngx_http_proxy_module  proxy代理模組
ngx_http_upstream_module  負載均衡模組

upstream www_server_pools {   #upstream 關鍵字 www_server_pools 叢集組的名字，可以自己起名字
　　server 10.1.1.1:80 weight=5;     #server關鍵字    ip/域名：埠， 預設80  weight權重

　　server 10.1.1.1:80 weight=5;　　　　#如果用域名解析，需要在hosts裡面有域名解析；或者內網有DNS

　　server www.abc.com:80 weight=5 backup;
　　server unix:/temp/backend3;   #指定socket檔案/可以不寫

}

通過proxy_pass 功能把使用者的請求交由上面反向代理upstream定義的tornadoes伺服器池處理

weight = 1 代表伺服器權重，預設值是1， 權重數字表示接受的請求比例越大；

max_fails = 1 nginx嘗試連線主機失敗的次數，這個值是配合proxy_next_upstream、fastcgi_next_upstram 和 memcached_mext_upstream三個引數來使用的。

backup  熱備配置（RS節點的高可用），噹噹前啟用的RS都失敗後會自動啟動熱備RS。這標誌這個伺服器作為備份伺服器，如果主宕機，就會向他轉發請求。注意：

當負載排程演算法為ip_hash時，後端伺服器不能是weight和backup

fail_timeout = 10s  在max_fails定義失敗次數後，距離下次檢查的間隔時間，預設是10s；如果是5，就檢測5次，如果5次都是502，那麼就等待10s在去檢查

down  標誌這伺服器永遠不可用，這個引數可以配合ip_hash使用

upstream 模組排程演算法

1.rr輪詢（預設排程演算法，靜態排程演算法）
相當於lvs的rr演算法，如果後端節點伺服器宕機（預設檢測80），自動會從節點地址池剔除

2.wrr（權重輪詢，靜態排程演算法）


例子：
upstream pools{
　　server 192.168.1.1 weight=1;
　　server 192.168.1.2 weight=2;

}

3.ip_hash(靜態排程演算法)
每個請求按客戶端的IP的hash進行分配；缺點可能道士分配不均無法保證1：1的負載均衡。比如客戶端的nat上網方式

例子：
upstream pools{
ip_hash;
server backend1.example.com;   #可以用ip
server backend2.example.com down;

}
注意：ip_hash時，不能有weight和backup

4.fair(動態排程演算法)

此演算法會根據後端節點伺服器的響應時間來分配請求，響應時間短的優先分配
nginx 本身不支援fair排程演算法，需要下載nginx的相關模組upstram_fair

例子：
upstream pool{
server 192.168.1.1;

server 192.168.1.2;
fair;
}

5.least_conn
此演算法會根據後端節點的連線數來決定分配情況，那個機器連線數少就分發。

6.url_hash演算法
和ip_hash 類似，這個是根據訪問 URL的hash分配的。同樣也不能寫入weight等
必須安裝nginx的哈市模組軟體包
例子：
upstream pools{
server queid1:1233;
server squid2:1233;
hash $request_uri;
hash_method crc32;
}

7.一致性hash演算法

Nginx反向代理

 http_proxy_module 模組

此模組可以將請求轉發到另一臺伺服器，在實際的反向代理工作中，或通過location功能指定URL，然後在接受到的符合匹配的URI的請求通過proxy_pass 拋給定義好的upstream節點池

案例：

1.將匹配URI為name的請求拋給http://127.0.0.1/remote/

location /name/ {
proxy_pass http://127.0.0.1/remote/;
}

2.將匹配URI為name的請求應用指定的rewrite規則，然後拋給http://127.0.0.0.1.

location /name/ {
　　rewrite /name/([^/]+) /users?name=$1 break;
　　proxy_pass http://127.0.0.1;


}