zabbix应用实战--Nginx监控详解
样例视频教程参考:
http://www.roncoo.com/course/view/fb3050a5b34b42f39ccad83ebebc89c1
龙果运维平台开源地址:https://github.com/roncoo/roncoo-cmdb
一、nginx监控说明:
1、监控指标:
基本活动指标
错误指标
性能指标
2、nginx 处理请求流程(图形):
注释:Accepts(接受)、Handled(已处理)、Requests(请求数)是一直在增加的计数器。Active(活跃)、Waiting(等待)、Reading(读)、Writing(写)随着请求量而增减
名称 |
描述 |
|
Accepts(接受) |
NGINX 所接受的客户端连接数 |
资源: 功能 |
Handled(已处理) |
成功的客户端连接数 |
资源: 功能 |
Active(活跃) |
当前活跃的客户端连接数 |
资源: 功能 |
Dropped(已丢弃,计算得出) |
丢弃的连接数(接受 – 已处理) |
工作:错误* |
Requests(请求数) |
客户端请求数 |
工作:吞吐量 |
NGINX worker 进程接受 OS 的连接请求时 Accepts 计数器增加,而Handled 是当实际的请求得到连接时(通过建立一个新的连接或重新使用一个空闲的)。这两个计数器的值通常都是相同的,如果它们有差别则表明连接被Dropped, 往往这是由于资源限制,比如已经达到 NGINX 的worker_connections的限制。
二、监控配置:
1、主要是基于nginx的status模块.在编译安装时候加上--with-http_stub_status_module.模块编译
2、修改配置文件开启nginx_status:
location /nginx_status {
stub_status on;
access_log off;
allow 192.168.1.100; 访问IP
deny all;
}
3、打开web 监控:
注释:
Active:当前活跃的连接数。
Accepts:接受的请求数
Handled:处理的请求数(正常服务器响应,这两项应该是可以相等的)
Requests:客户端处理的请求数。(吞吐量)
Reading:当接收到请求时,连接离开 Waiting 状态,并且该请求本身使 Reading 状态计数增加。在这种状态下 NGINX 会读取客户端请求首部。请求首部是比较小的,因此这通常是一个快速的操作。
Writing:请求被读取之后,其使 Writing 状态计数增加,并保持在该状态,直到响应返回给客户端。这意味着,该请求在 Writing 状态时, 一方面 NGINX 等待来自上游系统的结果(系统放在 NGINX “后面”),另外一方面,NGINX 也在同时响应。请求往往会在 Writing 状态花费大量的时间。
Waiting:活跃的连接也可以处于 Waiting 子状态,如果有在此刻没有活跃请求的话。新连接可以绕过这个状态并直接变为到 Reading 状态,最常见的是在使用“accept filter(接受过滤器)” 和 “deferred accept(延迟接受)”时,在这种情况下,NGINX 不会接收 worker 进程的通知,直到它具有足够的数据才开始响应。如果连接设置为 keep-alive ,那么它在发送响应后将处于等待状态
三、添加监控:
1、添加脚本:
[root@BJ-monitor-h-01 scripts]# cat nginx_status.sh
#!/bin/bash
# Script to fetch nginx statuses for tribily monitoring systems
# Author: xiaoluo
function active {
/usr/bin/curl "http://192.168.10.234/status" 2>/dev/null| grep 'Active' | awk '{print $NF}'
}
function reading {
/usr/bin/curl "http://192.168.10.234/status" 2>/dev/null| grep 'Reading' | awk '{print $2}'
}
function writing {
/usr/bin/curl "http://192.168.10.234/status" 2>/dev/null| grep 'Writing' | awk '{print $4}'
}
function waiting {
/usr/bin/curl "http://192.168.10.234/status" 2>/dev/null| grep 'Waiting' | awk '{print $6}'
}
function accepts {
/usr/bin/curl "http://192.168.10.234/status" 2>/dev/null| awk NR==3 | awk '{print $1}'
}
function handled {
/usr/bin/curl "http://192.168.10.234/status" 2>/dev/null| awk NR==3 | awk '{print $2}'
}
function requests {
/usr/bin/curl "http://192.168.10.234/status" 2>/dev/null| awk NR==3 | awk '{print $3}'
}
# Run the requested function
$1
2、zabbix配置文件添加自定义监控:
UserParameter=nginx[*],/usr/local/zabbix/scripts/nginx_status.sh $1
3、web界面添加item即可,以链接状态为例(类似的添加即可):
总结,导出nginx监控添加已经完成。
更多课程信息,请关注 龙果学院 官方网站http://www.roncoo.com/
或关注 龙果 微信公众号 RonCoo_com

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
Guava之EventBus
背景 天天说解耦解耦~事实上我们还没有mq 但是我们之前通过redis来模拟过queue进行消费 代码实现Redis异步任务 Redis实现优先级队列 都是很棒的实现办法 同时关于topic我们也可以通过redis的发布订阅来实现【当然持久化topic无法实现】 但是我们有时在项目中也需要简单的消息总线进行解耦~ 恰逢碰到瓜子二手车事件 来简单的介绍一下Guava的eventbus 分析 我们一直在说解耦解耦 究竟什么是耦合呢? 耦合性也叫块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块之间越独立则越差,模块间耦合的高低取决于模块间接口的复杂性,调用的方式以及传递的信息。 其实简单点说就是我们写代码不愿意吧代码写在一块~写在一块容易出现的问题比较多 而且由于依赖这个事件的越来越多也会使得这块代码越来越多 我们依赖一个消息 根据该消息就可以做各种操作【有没有想到观察者模式~~~】 事实上Guava提供了一种基于反射实现的解耦的方式EventBus【顾名思义 消息总线】 代码 首先初始化EventBus对象 分别对应到同步和异步 我们在...
-
下一篇
大数据查询——HBase读写设计与实践
背景介绍 本项目主要解决 check 和 opinion2 张历史数据表(历史数据是指当业务发生过程中的完整中间流程和结果数据)的在线查询。原实现基于 Oracle 提供存储查询服务,随着数据量的不断增加,在写入和读取过程中面临性能问题,且历史数据仅供业务查询参考,并不影响实际流程,从系统结构上来说,放在业务链条上游比较重。本项目将其置于下游数据处理 Hadoop 分布式平台来实现此需求。下面列一些具体的需求指标: 1、数据量:目前 check 表的累计数据量为 5000w+ 行,11GB;opinion 表的累计数据量为 3 亿 +,约 100GB。每日增量约为每张表 50 万 + 行,只做 insert,不做 update。 2、查询要求:check 表的主键为 id(Oracle 全局 id),查询键为 check_id,一个 check_id 对应多条记录,所以需返回对应记录的 list; opinion 表的主键也是 id,查询键是 bussiness_no 和 buss_type,同理返回 list。单笔查询返回 List 大小约 50 条以下,查询频率为 100 笔 / ...
相关文章
文章评论
共有0条评论来说两句吧...