Nginx状态监控

前言

最近公司项目在压测，接到一个需求要求将NG的并发状态做一个监控集成到管理端后台，百度了一下，才发现NG自身带有状态监测插件。

在Nginx的插件模块中有一个模块stub_status可以监控Nginx的一些状态信息，默认安装可能没有这个模块，手动编译的时候加一下即可。

插件安装

检查是否已安装

键入命令：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配置

在添加此模板之后，我们需要配置相关的状态访问路由

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即可访问对应的路由即可：

image.png

参数说明：

   active connections – 活跃的连接数量

　　server accepts handled requests — 总共处理了1075个连接 , 成功创建1064次握手, 总共处理了6253个请求

　　每个连接有三种状态waiting、reading、writing

　　reading —读取客户端的Header信息数.这个操作只是读取头部信息，读取完后马上进入writing状态，因此时间很短。

　　writing — 响应数据到客户端的Header信息数.这个操作不仅读取头部，还要等待服务响应，因此时间比较长。

　　waiting — 开启keep-alive后等候下一次请求指令的驻留连接.

　　正常情况下waiting数量是比较多的，并不能说明性能差。反而如果reading+writing数量比较多说明服务并发有问题。

image.png
image.png

• 当用户请求连接Nginx服务器时，accepts计数器会加一。且当服务器处理该连接请求时，handled计数器同样会加一。一般而言，两者的值是相等的，除非达到了某些资源极限（如worker_connection的限制）。

• 用户连接请求被处理，就会进入 active 状态。如果该连接没有其他 request，则进入 waiting 的子状态；如果有 request，nginx 会读取 request 的 header，计数器 request 加一，进入 reading 的子状态。 reading 状态持续时间非常短，header 被读取后就会进入 writing 状态。事实上，直到服务器将响应结果返回给用户之前，该连接会一直保持 writing 状态。所以说，writing 状态一般会被长时间占用。

其他命令

其实我们还可以使用命令获取

• 查看Nginx并发进程数：ps -ef | grep nginx | wc -l
• 查看Web服务器TCP连接状态：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将状态监控整合到我们的管理台来

image.png

好了，这样一个简单的NG监控就完成了。