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监控就完成了。

推荐阅读更多精彩内容