2015年11月18日星期三

web监控:zabbix自动发现+python之pycur模块对网站访问质量监控

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订
web监控:zabbix自动发现+python之pycur模块对网站访问质量监控  阅读原文»

用户名:sunday208 文章数:72 评论数:15
访问量:174755:2049:1162:5 注册日期:2008-05-08

一、效果图:

wKiom1ZLJ6PhCARDAAUWs8pXNuc408.jpg

wKioL1ZLJ_nDj1jwAATQJ4Tmzok200.jpg

wKiom1ZLJ6uyjgZoAARuTXFk0S0881.jpg

wKiom1ZLJ7PjdgwKAAXhCOMawWo018.jpg

二、需求说明:

最近需要对节点到源站、办公环境访问业务平台网站质量和办公网络线路质量的监控,简单的ping可以检测到一些东西,但是http请求的检查也要进行,于是就研究了下pycurl。

PycURl是一个C语言写的libcurl的python绑定库。libcurl 是一个自由的,并且容易使用的用在客户端的 URL 传输库。它的功能很强大,PycURL 是一个非常快速(参考多并发操作)和丰富完整特性的,但是有点复杂的接口。

三、python脚本:

1、编写httptime.py脚本

命令vi zabbix_agentd.conf.d/httptime.py

#!/usr/bin/python

# coding: UTF-8

import pycurl

import sys

import os

import json

class Test:

def __init__(self):

self.contents = ''

def body_callback(self,buf):

self.contents = self.contents + buf

def web_performance(input_url,mykey):

t = Test()

c = pycurl.Curl()

c.setopt(pycurl.WRITEFUNCTION,t.body_callback)

c.setopt(pycurl.ENCODING, 'gzip')

c.setopt(pycurl.URL,input_url)

c.perform()

if mykey == "NAMELOOKUP_TIME":

#DNS解析时间ms

NAMELOOKUP_TIME = c.getinfo(c.NAMELOOKUP_TIME)

print "%.2f"%(NAMELOOKUP_TIME*1000)

#return mykey

elif mykey == "CONNECT_TIME":

#建立连接时间ms

CONNECT_TIME = c.getinfo(c.CONNECT_TIME)

print "%.2f" %(CONNECT_TIME*1000)

#return mykey

elif mykey == "PRETRANSFER_TIME":

#准备传输时间ms

PRETRANSFER_TIME = c.getinfo(c.PRETRANSFER_TIME)

print "%.2f" %(PRETRANSFER_TIME*1000)

#return mykey

elif mykey == "STARTTRANSFER_TIME":

#传输开始时间ms

STARTTRANSFER_TIME = c.getinfo(c.STARTTRANSFER_TIME)

print "%.2f" %(STARTTRANSFER_TIME*1000)

#return mykey

elif mykey == "TOTAL_TIME":

#传输结束总时间ms

TOTAL_TIME = c.getinfo(c.TOTAL_TIME)

print "%.2f" %(TOTAL_TIME*1000)

#return mykey

elif mykey == "SIZE_DOWNLOAD":

#下载数据包大小bytes/s

SIZE_DOWNLOAD = c.getinfo(c.SIZE_DOWNLOAD)

print "%d" %(SIZE_DOWNLOAD)

#return mykey

elif mykey == "HEADER_SIZE":

#HTTP头部大小bytes

HEADER_SIZE = c.getinfo(c.HEADER_SIZE)

print "%d" %(HEADER_SIZE)

#return mykey

elif mykey == "SPEED_DOWNLOAD":

#平均下载速度bytes/s

SPEED_DOWNLOAD=c.getinfo(c.SPEED_DOWNLOAD)

print "%d" %(SPEED_DOWNLOAD)

#return mykey

def web_discovery():

website = ['www.qq.com','www.sina.com','sunday208.blog.51cto.com'];

devices = []

for devpath in website:

device = os.path.basename(devpath)

devices += [{'{#SITENAME}':device}]

print json.dumps({'data':devices},sort_keys=True,indent=7,separators=(',',':'))

if __name__ == '__main__':

if sys.argv[1] == "web_discovery":

web_discovery()

if sys.argv[1] == "web_performance":

input_url = sys.argv[2]

mykey = sys.argv[3]

web_performance(input_url,mykey)

2、加上执行权限:

命令chmod +xzabbix_agentd.conf.d/httptime.py

3、应用到zabbix客户端配置:

命令tail -1 zabbix_agentd.conf

UserParameter=HTTP_CURL[*],python /opt/soft/zabbix/etc/zabbix_agentd.conf.d/httptime.py $1 $2 $3

4、重启zabbix客户端:

/etc/init.d/zabbix_agentd restart

5、服务端测试:

命令如下:

zabbix_get -s 192.168.2.32 -p 10050 -k "HTTP_CURL[web_discovery]"

zabbix_get -s 192.168.2.32 -p 10050 -k "HTTP_C

服务器排障 之 nginx 499 错误的解决  阅读原文»

服务器排障 之 nginx 499 错误的解决

问题描述:

Nginx 服务器大量报错

  220.181.165.136 - - [18/May/2015:10:31:02 +0800] "POST /v1/jobsHTTP/1.1" 499 0 "" "bdHttpRequest/1.0.0"  115.239.212.7 - - [18/May/2015:10:31:03 +0800] "GET /v1/job/643309e3-dc73-4025-aa69-c9405c1d818fHTTP/1.1" 499 0"http://www.baidu.com/?tn=91638679_hao_pg&s_j=1""Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko"  140.207.202.187 - - [18/May/2015:10:30:58 +0800] "POST/v3/violations HTTP/1.1" 499 0 "-" "-"  42.236.10.71 - - [18/May/2015:10:30:59 +0800] "POST /v3/violationsHTTP/1.1" 499 0 "-" "-"  106.120.173.17 - - [18/May/2015:10:30:58 +0800] "POST/v3/violations HTTP/1.1" 499 0 "-" "Mozilla/5.0 (Windows NT6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131Safari/537.36"  180.97.35.164 - - [18/May/2015:10:30:52 +0800] "GET/v1/job/f86bdecc-2a61-4a42-bb7b-aa794b77f89b HTTP/1.1" 499 0"http://www.baidu.com/s?word=%E5%8D%81%E5%A0%B0%E5%A4%A9%E6%B0%94&tn=sitehao123&ie=utf-8""Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"  

问题分析:

出现的原因

google定义:

499 / ClientClosed Request

An Nginx HTTP server extension. This codeis introduced to log the case when the connection is closed by client whileHTTP server is processing its request, making server unable to send the HTTP header back

维基百科定义:

499Client Closed Request (Nginx)

Used in Nginx logs to indicate when the connection has been closed by client while the server is still processing itsrequest, making server unable to send a status code back

Nginx源码:

grep一下nginx源码,定义在ngx_request_t.h :

  /*  * HTTP does notdefine the code for the case when a client closed  * the connectionwhile we are processing its request so we introduce  * own code to logsuch situation when a client has closed the connection  * before we even tryto send the HTTP header to it  */  #define NGX_HTTP_CLIENT_CLOSED_REQUEST 499  

这是nginx定义的一个状态码,用于表示这样的错误:服务器返回http头之前,客户端就提前关闭了http连接

继续grep :

wKioL1ZK_oWDZn9NAAC_HrhuQAs422.png

很有可能是因为服务器端处理的时间过长,客户端"不耐烦"

要解决此问题,就需要在程序上面做些优化了。

再grep下"NGX_HTTP_CLIENT_CLOSED_REQUEST",发现目前这个状态值只在ngx_upstream中赋值

upstream在以下几种情况下会返回499:

  (1)upstream 在收到读写事件处理之前时,会检查连接是否可用:  ngx_http_upstream_check_broken_connection,      if (c->error) { //connecttion错误       ……          if (!u->cacheable) { //upstream的cacheable为false,这个值跟http_cache模块的设置有关。指示内容是否缓存。              ngx_http_upstream_finalize_request(r, u, NGX_HTTP_CLIENT_CLOSED_REQUEST);          }  }  

如上代码,当连接错误时会返回499。

(2)server处理请求未结束,而client提前关闭了连接,此时也会返回499。

(3)在一个upstream出错,执行next_upstream时也会判断连接是否可用,不可用则返回499。

总之,这个错误的比例升高可能表明服务器upstream处理过慢,导致用户提前关闭连接。而正常情况下有一个小比例是正常的。

继续分析:

问题的核心就是要排查为什么服务端处理时间过长

可能问题

1 后台python程序处理请求时间过长

2 mysql慢查询

通过查看监控:

1 cpu和内存的使用,都在正常范围

2 后台程序访问正常

3 MySQL没有慢查询

结果:

经过询问老大后得知,这个nginx为查询违章的api,用户提交查询后, python就去数据库或者交通局的网站查询。这个查询会有消耗一定的时间,所以,用户会主动断开连接

解决问题:

proxy_ignore_client_abort on; #让代理服务端不要主动关闭客户端的连接。

默认 proxy_ignore_client_abort 是关闭的,此时在请求过程中如果客户端端主动关闭请求或者客户端网络断掉,那么 Nginx 会记录 499,同时 request_time 「后端已经处理」的时间,而upstream_response_time "-" (已验证)

如果使用了 proxy_ignore_client_abort on ;

那么客户端主动断掉连接之后,Nginx 会等待后端处理完(或者超时),然后记录「后端的返回信息」到日志。所以,如果后端返回 200就记录 200 ;如果后端放回 5XX ,那么就记录 5XX

如果超时(默认60s,可以用 proxy_read_timeout 设置)Nginx 会主动断开连接,记录 504

注:只在做反向代理的时候加入,作为其他服务器的时候,关闭为好,默认设置是关闭的!

本文出自 "一个奋斗的小运维" 博客,请务必保留此出处http://yucanghai.blog.51cto.com/5260262/1713803

分享至 一键收藏,随时查看,分享好友!

没有评论:

发表评论