shell腳本日志分割

●隨著Nginx運行時間的增加，產生的日志也會逐漸增加，為了方便掌握 Nginx的運行
狀態，需要時刻關注Nginx日志檔案，太大的日志檔案對監控是一個大災難，不便于分析
排查，需要定期的進行日志檔案的切割，

●撰寫腳本/opt/fenge.sh##
把Nginx的日志檔案/usr/local/nginx/logs/access.log移動到,目錄/var/log/nginx下面，
以當前時間做為日志檔案的名稱，然后用kill -USR1創建新的日志檔案/usr/local/nginx/logs/access.log,
最后洗掉30天之前的日志檔案，

[root@www logs]# vi /opt/fenge.sh

#!/bin/bash
#Filename: fenge.sh
d=$(date -d "-1 day" "+%Y%m%d")
logs_path="/var/log/nginx"
pid_path="/usr/local/nginx/logs/nginx.pid"
[ -d $logs_path ] || mkdir -p $logs_path
mv /usr/local/nginx/logs/access.log ${logs_path}/51xit.top-access.log-$d
kill -USR1 $(cat $pid_path)
find $logs_path -mtime +30 | xargs rm -rf

命令決議
####創建日志檔案目錄
[ -d $logs_path ] || mkdir -p $logs_path

###移動并重命名日志檔案
mv /usr/local/nginx/logs/access.log l o g s p a t h / 51 x i t . t o p ? a c c e s s . l o g ? {logs_path}/51xit.top-access.log- logsp?ath/51xit.top?access.log?d

###重建新日志檔案
kill -USR1 $(cat $pid_path)

####翩除30天之前的日志檔案
find $logs_path -mtime +30 | xargs rm -rf

執行/opt/fenge.sh,測驗日志檔案是否被切割

[root@localhost ~]# chmod +x fengge.sh     
[root@localhost ~]# ./fengge.sh 
[root@localhost ~]# ls /var/log/nginx/
51xit.top-access.log-20200908

這里可以看到按日期分割了日志檔案

[root@localhost ~]# cat /usr/local/nginx/logs/access.log

原來的日志檔案沒有了 重新創建了

設定連接超時

●在企業網站中，為了避免同一個客戶長時間占用連接，造成資源浪費，可設定相應的連
接超時引數，實作控制連接訪問時間，可以修改組態檔nginx.conf，設定keepalive_timeout
超時時間，

●keepalive_timeout第一個引數指定了與client的keep-alive連接超時時間，服務器將
會在這個時間后關閉連接，可選的第二個引數指定了在回應頭Keep-Alive: timeout=time中
的time值，這個頭能夠讓一些瀏覽器主動關閉連接，這樣服務器就不必要去關閉連接了，
沒有這個引數，nginx不會發送Keep-Alive回應頭，

●訪問網址抓取資料報文，回應頭中顯示了超時時間是180秒，一般只設定Keepalive_timeout引數即可，
同時在優化后可能還會增加其它超時引數，比如Client_header_timeout引數，指定等
待客戶端發送請求頭的超時時間，Client_body_timeout指定請求體讀超時時間

[root@localhost ~]# vi /usr/local/nginx/conf/nginx.conf
http {
........//省略內容
keepalive_timeout 65 180;                    ####修改
client_header_timeout 80;                    ##在下面添加
client_body_timeout 80;                      ##在下面添加
........//省略內容


[root@localhost ~]# systemctl restart nginx

清除瀏覽器快取訪問驗證： 20.0.0.26
keep-Alive: timeout=180\r\n
成功了

Nginx深入優化

更改行程數

在高并發環境中，需要啟動更多的Nginx行程以保證快速回應，用以處理用戶的請求，
避免造成阻塞

首先查看以下Nginx運行行程的個數

[root@localhost ~]# ps aux | grep nginx
root      11926  0.0  0.0  20556   628 ?        Ss   07:47   0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx     11927  0.0  0.0  21008  1596 ?        S    07:47   0:00 nginx: worker process
root      11932  0.0  0.0 112724   988 pts/0    S+   07:51   0:00 grep --color=auto nginx

這里我們看到其中master process 是Nginx的主行程，開啟了1個,worker process是子行程，子
行程也是開啟了1個，

●修改Nginx的組態檔的worker_processes引數，一般設為CPU 的個數或者核數
在高并發的情況下可設定為CPU個數或者核數，可以查看CPU的核數以確定引數

[root@localhost ~]# cat /proc/cpuinfo | grep -c "physical"
8

引數設定為8，和CPU的核數相同，運行行程數多一些，回應客戶端訪問請求時，Nginx
就不會臨時啟動新的行程提供服務，減少了系統的開銷，提升了服務速度

[root@localhost ~]# vi /usr/local/nginx/conf/nginx.conf

worker_processes  8;

修改完后，重啟服務，使用 ps aux 查看運行行程數的變化情況，

[root@localhost ~]# systemctl restart nginx                   
[root@localhost ~]# ps aux | grep nginx

root      11948  0.0  0.0  20556   692 ?        Ss   07:55   0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx     11949  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
nginx     11950  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
nginx     11951  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
nginx     11952  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
nginx     11953  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
nginx     11954  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
nginx     11955  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
nginx     11956  0.0  0.0  21008  1344 ?        S    07:55   0:00 nginx: worker process
root      11958  0.0  0.0 112724   988 pts/0    S+   07:56   0:00 grep --color=auto nginx

●開啟了1個主行程和8個子行程，引數設定起到了作用，
默認情況下，Nginx的多個行程可能更多的跑在一顆CPU上，可以分配不同的行程給
不同的CPU處理，充分利用硬體多核多CPU，在一臺8核CPU服務器上，可以設定每個
行程分別由不同的 CPU 核心處理，達到CPU 的性能最大化，

配置網頁壓縮

●Nginx的ngx_http_gzip_module壓縮模塊提供了對檔案內容壓縮的功能，允許Nginx
服務器將輸出內容發送到客戶端之前進行壓縮，以節約網站的帶寬，提升用戶的訪問體驗,
默認 Nginx 已經安裝該模塊，只需要在組態檔中加入相應的壓縮功能引數對壓縮性能進
行優化即可，

#             gzip on;    開啟gzip壓縮輸出;
#             gzip_min_length 1k:用于設定允許壓縮的頁面最小位元組數;
#             gzip_buffers 4 16k:表示申請4個單位為16k的記憶體作為壓縮結果流快取，默認值
是申請與原始資料大小相同的記憶體空間來存盤gzip壓縮結果;

#              Zip_http_version 1.0:用于設定識別http 協議版本，默認是1.1，目前大部分瀏覽
器已經支持gzip解壓，但處理最慢，也比較消耗服務器CPU 資源;

#              Gzip_comp_level 2:用來指定gzip壓縮比，1壓縮比最小，處理速度最快;9壓縮
比最大，傳輸速度快，但處理速度最慢，使用默認即可;

#              Gzip_types text/plain:壓縮型別，是對哪些網頁檔案啟用壓縮功能;
#              Gzip_vary on:選項可以讓前端的快取服務器快取經過gzip壓縮的頁面

下面開始配置

[root@localhost ~]# vi /usr/local/nginx/conf/nginx.conf

gzip on;                                 去掉#
gzip_buffers 4 64k;
gzip_http_version 1.1;
gzip_comp_level 2;
gzip_min_length 1k;
gzip_vary on;
gzip_types text/plain text/javascript application/x-javascript text/css text/xml application/xml application/xml+rss;

[root@localhost ~]# systemctl restart nginx

驗證：
在Nginx作業目錄建立一個超過1K大小的html檔案，然后訪問網址抓取資料報文

配置防盜鏈

●在企業網站服務中，一般都要配置防盜鏈功能，以避免網站內容被非法盜用，造成經濟
損失，也避免了不必要的帶寬浪費，Nginx的防盜鏈功能也非常強大，在默認情況下，只需
要進行很簡單的配置，即可實作防盜鏈處理，

●防盜鏈需要準備兩臺主機,有一臺模擬盜鏈

IP地址
20.0.0.26
20.0.0.25

域名
26：www.51xit.top 源主機
25：www.52.xit.top 盜鏈主機

為了方便驗證需要修改Windows的C:\Windows\System32\drivers\etc\hosts檔案，設定域名和映射關系：

20.0.0.26 www.51xit.top Nginx
20.0.0.25 www.test.com Apache

做完以后ping一下這兩個網站，通了繼續

這里我用工具添加了一張圖片進去

[root@localhost html]# systemctl restart nginx

#重繪一下Nginx程式，用瀏覽器訪問www.51xit.top

20.0.0.25 主機：開始盜鏈

首先打開20.0.0.26主機的域名：www.51xit.top,把網頁地址復制下來

#下面為主機20.0.0.25的盜圖配置操作：

[root@localhost ~]# systemctl start httpd
[root@localhost ~]# cd /usr/local/httpd/htdocs/
[root@localhost htdocs]# vi index.html

!DOCTYPE html>
<html>
<head>
<p><em>盜版圖網站</em></p>
<img src="http://www.51xit.top/zz.jpg" / >
</body>
</html>


#這里把你復制的網址填進去

接下來我們正常訪問www.52xit.top 可以看到圖片正常打開，盜圖成功

20.0.0.26主機：配置防盜鏈

●Nginx的防盜鏈原理是加入location項，用正則運算式過濾圖片型別檔案，對于信任的
網址可以正常使用，不信任的網址回傳相應的錯誤圖片，在源主機(bt.com）的組態檔中
加入以下代碼:

[root@localhost html]# vi /usr/local/nginx/conf/nginx.conf

#########在第一個     location / { } 下面插入    ###############
        location ~ \.(gif|jpg|jepg|png|bmp|ico)$ {
            root   html;
            expires 1d;
            valid_referers none blocked *.51xit.top 51xit.top;
            if ($invalid_referer) {
               rewrite ^/ https://ss1.bdstatic.com/70cFvXSh_Q1YnxGkpoWK1HF6hhy/it/u=2135575968,1508481517&fm=15&gp=0.jpg;
            }
        }

#這里用if判斷，用rewrite跳轉，后面的地址是我從百度搜來的圖片
#哈哈，等我盜了別人的圖片，給了第三個人用

[root@localhost html]# systemctl restart nginx    重啟

~* .(jpglgif|swf)$ : 這段正則運算式表示匹配不區分大小寫，以.jpg或.gif或.swf結尾的圖片格式

接下來我們清除瀏覽器快取重新打開www.52.xit.top，圖片實作跳轉了！！

FPM 引數優化

ginx的PHP決議功能實作如果是交由FPM處理的，為了提高 PHP的處理速度，可
對FPM模塊進行引數的調整，
下面是執行步驟:

1）安裝帶 FPM 模塊的 PHP環境，保證 PHP可以正常運行，
2) FPM行程有兩種啟動方式，由pm 引數指定，分別是 static和dynamic，前者將產
生固定資料的fpm行程，后者將以動態的方式產生fpm行程，

Static的方式可以使用pm.max_children 指定啟動的行程數量，Dynamic方式的引數要
根據服務器的記憶體與服務負載進行調整，

            選項                                                     描述
Pm.max children                                       指定啟動的行程數量最大的數量
Pm.start.servers                                      動態方式下初始的ftpm行程數量
Pm.min_spare_servers                                  動態方式下最小的fpm空閑行程數
Pm_max_spare_servers                                  動態方式下最大的空閑行程數

假設:現有云服務器，運行了個人論壇，記憶體為1.5G,fpm行程數為20，記憶體消耗近
1G，處理比較慢，對引數進行優化處理，

[root@localhost html]# cd /usr/local/php/etc/php-fpm.d
[root@localhost html]# vi www.conf

pm=dynamic
pm.max_children=20
pm.start_servers=5
pm.min_spare_servers=2
pm.max_spare_servers=8

#FPM啟動時有5個行程，最小空閑2個行程，最大空閑8個行程，最多可以有20個
行程存在