Chinaunix首页 | 论坛 | 博客
  • 博客访问: 380193
  • 博文数量: 237
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 0
  • 用 户 组: 普通用户
  • 注册时间: 2016-06-12 14:40
个人简介

  每个人生的当口,都是会有一个孤独的时刻,四顾无人,只有自己,于是不得不看明白自己的脆弱,自己的欲望,自己的念想,自己的界限,还有,自己真正的梦想。

文章分类

全部博文(237)

文章存档

2017年(3)

2016年(234)

分类: LINUX

2016-05-11 15:05:30

服务器换机房后cacti监控不出图故障排查

环境介绍:

因为业务需要,公司在深圳机房的几台服务器搬迁到中山机房,由于监控服务器放在佛山,因此采用如下图的方式来对中山机房的机器进行监控:

佛山的监控系统采用cacti+nagios来监控,B服务器为windows机器,没有公网IP。因此cactinagios获取数据的时候需要通过A服务器(linux)iptables来转发。如上图,cacti通过访问A服务器的11161端口来访问B服务器的snmp服务(snmp服务使用的端口为udp161端口)。在A服务器上添加了如下iptables规则来实现端口转发的目的:

# nagioswindows客户端NSClient的端口转发,nagios通过这个端口采集数据

/sbin/iptables -t nat -A PREROUTING -d 189.43.138.11 -p tcp -m tcp --dport 12489 -j DNAT --to-destination 172.16.100.82:12489

#windowssnmp的端口转发,cacti通过这个端口采集数据

/sbin/iptables -t nat -A PREROUTING -d 189.43.138.11 -p udp -m udp --dport 11161 -j DNAT --to-destination 172.16.100.82:161

#B服务器的IP地址进行伪装,使B服务器能正常上网

/sbin/iptables -t nat -A POSTROUTING -s 172.16.100.0/24 -j SNAT --to-source 189.43.138.11

机器迁移以后因为IP变了因此只对一些涉及到IP的配置做了变更,变更后网站访问以及ssh登录等都正常,nagios监控的也正常,唯独cacti没有数据。奇怪的是以前在深圳机房的时候也是采取的iptables规则来做端口转发的,能正常地获取数据。现在不同的只是将IP变更了一下就出现不能获取数据的问题,检查了windows下的防火墙以及杀毒软件没有阻塞对161端口的访问,不知道什么原因?


故障排查:

         为了深入分析这个问题,首先在监控服务器上使用snmpwalk命令看看能否获取数据,命令如下:

snmpwalk -v2c -c public 189.43.138.11: 11161

#返回如下内容

Timeout: No Response from 189.43.138.11: 11161

发现没有内容返回,在监控服务器上ping 189.43.138.11没有问题。为了一探究竟在A服务器上使用tcpdump抓包

A服务器使用如下命令抓包:

/usr/sbin/tcpdump -i eth1 port 11161 –vv

返回如下内容:

18:44:30.650302 IP (tos 0x0, ttl  58, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) 121.9.203.157.13065 > 189.43.138.11.suncacao-snmp: [udp sum ok] UDP, length 54

18:44:31.651067 IP (tos 0x0, ttl  58, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) 121.9.203.157.13065 > 189.43.138.11.suncacao-snmp: [udp sum ok] UDP, length 54

备注:由于后面几个包和这两个包一样,限于篇幅,省略了。

从抓取的包中我们可以看出数据顺利的到了189.43.138.11服务器,但是从189.43.138.11却没有数据返回。

于是在B服务器使用ethereal进行抓包分析。通过161端口进行过滤后发现如下内容:

发现返回的IP确实172.16.100.83IP,也就是B服务器上另外一个IP,对于这个IP我们的防火墙上没有任何规则。至此真相大白!


故障原因:

         从上面的分析中我们可以看出,我们的规则之是针对172.16.100.82这个IP,但是B服务器上snmp响应的IP确实172.16.100.83这个IP,因为A上的iptables只是针对172.16.100.82这个IP做了规则,因此导致数据返回监控服务器的时候出现问题。以前在深圳机房的时候只配置了一个IP,因此没有出现这个问题。

解决办法:

         知道了问题的原因,就好解决了,只需要将防火墙规则指向172.16.100.83这个IP即可或者将172.16.100.83这个IP去掉,因为那个IP是同事配置的因此采用第一种解决办法,于是将snmp端口转发的规则调整如下:

#windowssnmp的端口转发,cacti通过这个端口采集数据

/sbin/iptables -t nat -A PREROUTING -d 189.43.138.11 -p udp -m udp --dport 11161 -j DNAT --to-destination 172.16.100.83:161

再使用snmpwalk在监控服务器上获取一下数据看看:

snmpwalk -v2c -c public 189.43.138.11:11161

SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 6 Model 26 Stepping 5 AT/AT COMPATIBLE - Software: Windows Version 5.2 (Build 3790 Multiprocessor Free)

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.311.1.1.3.1.2

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (915656) 2:32:36.56

SNMPv2-MIB::sysContact.0 = STRING:

SNMPv2-MIB::sysName.0 = STRING: WEB2

哈哈,终于有数据了,再看看cacti中也开始有数据了。看来排查这种问题,还是需要通过抓包的方式来定位问题,比较快速!


故障总结:

         对于我们IT人员来说掌握各个平台下的抓包工具的使用也是一项很重要的技能,有了这些技能我们才能在复杂的和高压力的IT工作环境中脱颖而出,达到事半功倍的效果。在工作当中如果遇到网络不通或者是获取不了数据的情况,采用抓包的方法来分析能快速的定位问题。因此,在这里也希望通过这个问题的总结让更多的人重视一些IT工具的积累和使用。

 

 

阅读(504) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~