nagios和pycurl的超时时间

 线上使用自己开发的url monitor工具进行应用层面的监控,主要的原理使用nagios驱动pycurl做url的检测,url的检测属性(ip,port,url,httpcode等)是放在数据库里面的。
对于http code的监控,当获取的http code和期望的http code不一致时,产生报警邮件。

最近发现在报警邮件中,有显示current http code是200,但是nagios的状态却是critical的情况。

报警邮件:

wKiom1L1z2DhybFaAAF2Z2DjHJA372.jpg

spacer.gif

通过nagios的页面查看,确实看到了监控报错的情况:

nagios页面:

spacer.gif wKioL1L1z0riGUW4AAFovXHbi3k735.jpg


分析nagio的报判断的几种状态:

soft:监控项处于retry_check检测周期内的非正常状态
hard:监控项达到max_check_attempts最大次数后的非正常状态
常态:soft和hard之外的状态

线上关于这个service的配置:
                check_interval         3           
                retry_interval         1            
                max_check_attempts     3    

即检测间隔为3分钟,检测间隔为1分钟,最大重试3次。当第一次失败后,进入soft1,间隔1分钟后继续检测,失败进入soft2,当第3次同样失败时,进入hard状态。
进入hard状态后,就会每间隔3分钟检测。(注:进入soft状态后, 按retry_interval的时间检测,不按check_interval的时间检测,直到恢复常态或hard )

从nagios的结果可以看出,是由于service check超时导致,nagios的service check和pycurl都是有超时设置的,产生这种问题的原因就是在nagios的超时时间内,pycurl没有正常返回值,导致nagios任务检测失败。但是pycurl的超时时间比较长,最终返回了正确的值update到了数据库,但是nagios确认为检测失败了。。

在pycurl中控制超时的设置是CONNECTTIMEOUT(默认300s),TIMEOUT(永不超时)

而nagios的模式设置service_check_timeout模式时60s.


解决方法:
对pycurl的超时参数做设置,小于nagios的超时时间即可。

具体的pycurl的代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
def  check_server_url(proxy,url,location):
         buf_header  =  cStringIO.StringIO()
         =   pycurl.Curl()
         c.setopt(c.URL,url)
         c.setopt(c.CONNECTTIMEOUT, 20 )
         c.setopt(c.TIMEOUT, 40 )
         if  location  = =  0 :
                 c.setopt(c.FOLLOWLOCATION, 0 )
         else :
                 c.setopt(c.FOLLOWLOCATION, 1 )
         c.setopt(c.PROXY,proxy)
         c.setopt(c.HEADERFUNCTION,buf_header.write)
         c.setopt(c.NOBODY, True )
         try :
                 c.perform()
                 http_code  =  c.getinfo(c.HTTP_CODE)
                 print  http_code
                 http_hearder  =  buf_header.getvalue()
         except  pycurl.error:
                 http_code  =  "-1"
         c.close()
         buf_header.close()
         return  http_code


其实最根本的rc还是业务响应慢导致(最终定位为db的响应慢)。



本文转自菜菜光 51CTO博客,原文链接:http://blog.51cto.com/caiguangguang/1357283,如需转载请自行联系原作者

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值