引言

這篇文章將介紹當WEB服務器報警，提示磁盤使用率問題和帶寬滿載時的一些排查思路和解決方案。

首先，我們一定要配置服務器的云監控，如果是云廠商的服務器都有監控服務，開通即可。

如果是自建機房，監控報警策略也是必須搭建的。

磁盤使用率報警

原因分析

• 日志沒有及時遷移或清理
• 程序異常輸出了大量的垃圾文件
• 掛載的硬盤存儲空間不足，不適應業務發展，需要掛載新的磁盤。

解決方案

1. 日志遷移或清理

我們需要Nginx日志和項目運行中的關鍵日志，方便定位問題、數據分析。

日志遷移的思路很簡單，目前主流的云廠商都支持日志遷移和存儲服務，且成本不高。

如果是自建的服務，可以掛載專門的存儲硬盤，不和業務服務器耦合在一起，將日志進行單獨存儲。

2. 日志清理

• 切換到根目錄

cd /

• 查找到大文件，比如找到大于100M的文件

find . size +100M

• 沒用的日志大文件置為空(不要直接刪除，正在被使用的文件是無法直接刪除的)

cat /dev/null > /data/logs/php-fpm/error.log

網站流量異常，一直在報警

當網站流量報警時喜憂參半，如果是因為搞活動或者網站內容命中了熱點，被搜索引擎推薦，那真是像買彩票中獎一樣高興。

不過，大多數情況，網站在毫無預兆的情況下突然打滿帶寬，大概率是被惡意攻擊了。

下面介紹一下我的排查思路

首先我登錄了網站的統計服務平臺，發現PV/UV等關鍵數據并沒有太大變化，但是服務器的帶寬卻被打滿了，說明異常流量不是通過刷網站頁面導致的，可能是通過刷接口導致的。

通過分析日志排查異常流量

首先切換到日志目錄，比如我的目錄是

cd /data/logs/nginx

查看訪問最頻繁的前10個IP

awk '{print $1}' access.log | sort -n |uniq -c | sort -rn | head -n 10

分析結果：

• 發現訪問量最高的ip是自身服務器的外網ip
• 發現有一組美國谷歌云的異常訪問
• 發現有一個北京xx網的異常訪問
• 其他基本是正常流量

解決異常流量

公網ip訪問量最大：

這是一個N年前的老項目，開發時是有一些知識盲點的，沒有考慮到內網傳輸要比外網傳輸的速度快很多。

通過下面的方式替換了外網傳輸為內網傳輸：

• 項目中的外網ip替換為內網ip（發現項目代碼并沒有直接訪問外網ip，而是訪問了子項目的域名）
• 配置Linux服務器的host

# 打開Linux的hosts配置文件
vim /etc/hosts
# 將項目中請求的多個域名解析到本地的ip地址
127.0.0.1 多個域名用空格分隔

優化完內網傳輸之后，就開始最重要的事情了：

封禁惡意ip

• 創建（打開）黑名單配置文件

 vim /etc/nginx/blackip.conf

• 將black.conf添加到nginx.conf中 (代碼段中的...代表省略的內容)

http{
.
.
.
    #ip黑名單
    include /etc/nginx/blackip.conf;
.
.
.
}

• 添加要封禁的黑名單

#屏蔽單個ip訪問
deny IP; 
#允許單個ip訪問
allow IP; 
#屏蔽所有ip訪問
deny all; 
#允許所有ip訪問
allow all; 
#屏蔽整個段：從127.0.0.1到127.255.255.254
deny 127.0.0.0/8;
#屏蔽IP段：從127.45.0.1到127.45.255.254
deny 127.45.0.0/16;
#屏蔽IP段：從127.45.6.1到127.45.6.254
deny 127.45.6.0/24;

• 重啟Nginx服務

nginx -s reload

停掉不用的服務

在查詢Nginx的log時，發現一些不再用的服務仍然有請求日志。

果斷停掉這些服務。

統計訪問最多的url 前10名

cat access.log |awk '{print $7}'| sort|uniq -c| sort -rn| head -10 | more

封禁了不再使用url

• 小程序接口封禁
• 網站快報相關的接口封禁

優化結果

在進行上述操作后，收到了服務器報警恢復正常的短信通知。

今天早晨登錄服務器監控后臺，發現效果是灰常明顯的：

紅線左側是處理異常流量前的帶寬波動圖，右側是處理后的波動圖，淺色波動線是昨天的流量情況。

總結

這是7年前剛入行時做的項目，單機部署，排查思路比較簡單清晰：查日志，封ip。

在微服務+分布式成為主流的今天，又要用哪些思路和工具排查問題呢？