kibana配置nginx_Nginx监控方案

点击上方"蓝字"，关注了解更多

Nginx是一个开源的HTTP和反向代理服务器，采用异步非阻塞工作模型，具备高并发、低资源消耗的特性，高度模块化设计使其具备很好的扩展性，是很多网站的流量入口。它的性能及状态直接影响了整个网站所能抗住的并发量，本文将围绕Nginx的监控方案做一个探讨。

基础监控

基础监控主要是监控Nginx所在服务器的硬件类指标，包括：CPU使用率，CPU负载情况，内存使用情况，磁盘空间，磁盘IO，网卡流量，端口状态等指标，这些监控通过一些基础的工具就可做到，如zabbix等。可通过WEB界面设置或查看监视结果，也可以配置规则利用Email，短信等告警通知。

请求监控

请求监控主要针对服务入口流量进行监控，统计所有的真实请求，在流量异常时第一时间发出告警，有利于决策集群规模，及时做出应对响应。

监控方案一：

利用Nginx的 --with-http_stub_status_module 模块进行请求监控(./nginx -V查看，没有此模块的Nginx需重新编译)。nginx.conf需增加如下配置：

然后通过http请求:curl http://localhost:9999/nginx_status即可获取当前请求信息。如下图：

响应结果含义：

Active connections：表示Nginx正在处理的活动连接数有多少个。

Server：表示Nginx启动到现在共处理了多少个连接。

accepts：表示Nginx启动到现在共成功创建了多少次握手(备注：请求丢失数=握手数-连接数)。

handled requests：表示总共处理了多少次请求。

Reading：表示Nginx读取到客户端的Header信息数。

Writing：表示Nginx返回给客户端的Header信息数。

Waiting：表示Nginx已经处理完正在等待下一次请求指令的驻留连接。

可以通过定时请求，收集解析数据，绘制实时，日环比，周同比等曲线，随时关注流量情况。结合机器压力测试后的指标数据设置合适的告警阈值。

还可为整体架构方案，重大活动等做理论支撑。

监控方案二：

当Nginx不能安装 --with-http_stub_status_module 模块时候，可通过accesslog的量来获取当前请求量。

通过命令wc -l /logdata/access.log | awk '{print $1}' 可以获取当前accesslog行数，然后利用linux的crontab做分钟级的定时任务，定时获取accesslog行数。两次相减即为每分钟的请求量。

      此方法不是很精确，错误的请求也会统计不到，仅能起到参考作用。 进阶监控

除了服务器的一些参数、请求流量，Nginx的日志中也包含很多重要的信息，我们也希望这些信息可以更直观方便的展示出来。ELK正好满足这一点，可以使用其搭建的实时日志分析平台对Nginx做进阶监控。

通过ELK我们可以实现以下功能：

1、精准条件查询：一级域名、二级域名、客户真实IP、HTTP状态码、HTTP方法、request_time、response_time、代理IP、body_bytes_sent等；

2、模糊条件查询：全部字段都可以进行模糊查询；

3、流量分析：整体或单独域名或者具体错误码等等的流量走势分析；

4、离线数据分析：过去一个周期内(1天、1周、1月)所有请求构成分析；

5、监控告警：实时监控爬虫IP过高的频率访问(如单个IP1秒钟请求超过100次报警)；实时监控错误状态请求情况(如单个域名1秒出现100个500就报警)等等。

具体实现：

通常做法如上图所示，在每个Nginx节点处安装Filebeat客户端，监听指定的日志文件或位置，收集日志信息；数据发送到Logstash，进行统一规整或者进行一些业务处理；处理完的数据存入ES中；最后通过Kibana进行可视化展示或者自定义查询。如果数据量较大，可使用Kafka做缓存。

    Filebeat是一个轻量级的数据收集系统，占用资源少性能高，但是数据处理能力比较弱；反观Logstash，对数据过滤分析能力很强组件丰富，但是资源占用比较多。为了避免收集程序影响Nginx的性能，而且希望用到Logstash丰富的组件，所以这里在Nginx节点处使用Filebeat而不是直接使用Logstash。