前言
最近公司項目在壓測,接到一個需求要求將NG的并發(fā)狀態(tài)做一個監(jiān)控集成到管理端后臺,百度了一下,才發(fā)現NG自身帶有狀態(tài)監(jiān)測插件。
在Nginx的插件模塊中有一個模塊stub_status可以監(jiān)控Nginx的一些狀態(tài)信息,默認安裝可能沒有這個模塊,手動編譯的時候加一下即可。
插件安裝
檢查是否已安裝
鍵入命令:nginx -V 2>&1 | grep -o with-http_stub_status_module
[root@prod-l27-43-26 logs]#
[root@prod-l27-43-26 logs]# nginx -V 2>&1 | grep -o with-http_stub_status_module
with-http_stub_status_module
[root@prod-l27-43-26 logs]#
如果有返回結果則證明已安裝了此插件,如果沒有,則需要重新編譯去安裝,編譯命令如下:
./configure –with-http_stub_status_module
修正NG配置
在添加此模板之后,我們需要配置相關的狀態(tài)訪問路由
location /ngstate {
stub_status on;
access_log off;
#allow 127.0.0.1;
#deny all;
#auth_basic "NginxStatus";
#auth_basic_user_file conf/nginxstaus;
}
修改之后,重啟NG即可訪問對應的路由即可:
參數說明:
active connections – 活躍的連接數量
server accepts handled requests — 總共處理了1075個連接 , 成功創(chuàng)建1064次握手, 總共處理了6253個請求
每個連接有三種狀態(tài)waiting、reading、writing
reading —讀取客戶端的Header信息數.這個操作只是讀取頭部信息,讀取完后馬上進入writing狀態(tài),因此時間很短。
writing — 響應數據到客戶端的Header信息數.這個操作不僅讀取頭部,還要等待服務響應,因此時間比較長。
waiting — 開啟keep-alive后等候下一次請求指令的駐留連接.
正常情況下waiting數量是比較多的,并不能說明性能差。反而如果reading+writing數量比較多說明服務并發(fā)有問題。
當用戶請求連接Nginx服務器時,accepts計數器會加一。且當服務器處理該連接請求時,handled計數器同樣會加一。一般而言,兩者的值是相等的,除非達到了某些資源極限(如worker_connection的限制)。
用戶連接請求被處理,就會進入 active 狀態(tài)。如果該連接沒有其他 request,則進入 waiting 的子狀態(tài);如果有 request,nginx 會讀取 request 的 header,計數器 request 加一,進入 reading 的子狀態(tài)。 reading 狀態(tài)持續(xù)時間非常短,header 被讀取后就會進入 writing 狀態(tài)。事實上,直到服務器將響應結果返回給用戶之前,該連接會一直保持 writing 狀態(tài)。所以說,writing 狀態(tài)一般會被長時間占用。
其他命令
其實我們還可以使用命令獲取
- 查看Nginx并發(fā)進程數:ps -ef | grep nginx | wc -l
- 查看Web服務器TCP連接狀態(tài):netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
[root@prod-l27-43-26 nginx]# ps -ef | grep nginx | wc -l
18
[root@prod-l27-43-26 nginx]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 31
TIME_WAIT 21
[root@prod-l27-43-26 nginx]#
整合
最好我們可以通過API將狀態(tài)監(jiān)控整合到我們的管理臺來
好了,這樣一個簡單的NG監(jiān)控就完成了。